ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 45836] New: [PATCH] For correct empty CBzip2OutputStream handling
Date Thu, 18 Sep 2008 18:09:07 GMT

           Summary: [PATCH] For correct empty CBzip2OutputStream handling
           Product: Ant
           Version: 1.8Alpha (nightly)
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Other

Created an attachment (id=22604)
 --> (
Patch to fix empty CBzip2OutputStream

In 1.7.1, creating and then closing a CBzip2OutputStream without writing any
dya to it would incorrectly result in an ArithmeticException being thrown (bug
32200).  The code in svn has been modified so this no longer happens.  However,
the resulting compressed output is no longer valid and won't decompress with
bunzip2 after prepending "BZ" to the stream.

Here's a patch against the code in svn that fixes the problem correctly as far
as I can tell.

Here's a test program:

$ cat

class X {
    public static void main(String[] args) throws Exception {
        new CBZip2OutputStream(System.out).close();

Example incorrect 1.7.1 behavior:

$ java X
Exception in thread "main" java.lang.ArithmeticException: / by zero
        at X.main(

Example incorrect behavior of current code:

$ (echo -n "BZ"; java X) | bunzip2

bunzip2: Data integrity error when decompressing.
        Input file = (stdin), output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

Behavior with this patch applied, bunzip2 creates zero-length output as

$ (echo -n "BZ"; java -cp .:/tmp/ant-svn/src/main X) | bunzip2 | wc -c

Note that last is set to -1 only in initBlock() which is called only from the
constructor and from writeRun().  However, after initBlock() is called from
writeRun(), writeRun() calls itself again and last is guaranteed not to be -1
afterwards.  Therefore my last == -1 check is true only if the stream is empty,
and in all other cases the behavior is not changed.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

View raw message