Name: zl72593 Date: 11/10/98


The actual errors were encountered on reading a zip stream with gzip compression.

The scenario was as follows (simplified to an equivalent illustrative skeleton):

thread1 on java VM1:

//note the data to be compressed ranges from a few k to a few megabytes
//we hard code 300000 in this ilustration

byte[] b = new byte[300000]; //and fill it with data (a serialized blob)
ByteArrayOutputStream s = new ByteArrayOutputStream(b.length);
GZIPOutputStream z = new GZIPOutputStream(s);
z.write(b);
z.close;
byte[] c = s.toByteArray();

//c and the compressed and uncompressed lengths are sent
//and flushed on a socket...

thread2, coincidentally on java VM1:

//the compressed and uncompressed lengths are read from
//a connected socket (DataInputStream dis)

byte[] c = new byte[len]; //the compressed length
dis.readFully(c, 0, len);
ByteArrayInputStream s = new ByteArrayInputStream(c);
GZIPInputStream z = new GZIPInputStream(s);
Byte[] b = new byte[300000]; //the uncompressed length
int residual = 300000;
int offset = 0;
while (residual > 0) {
int i = z.read(b, offset, residual); //####
if (i < 0) throw new Exception("aaaargh");
offset += i;
residual -=i;
}

The z.read() above did not work - it got an exception.
Actually it usually works, but it can get one of the following:
"java.util.zip.ZipException: invalid stored block lengths"
or
"java.util.zip.ZipException: oversubscribed dynamic bit lengths tree"

We have scrutinized our code to see if the socket stream can be corrupted by concurrent unsynchronized access to it but believe that this is impossible. We would like to know if there are any bugs in the zlib.so that we should know about (in particular relating to reentrancy) and would like to know more about the implications of the above error messages. In the meantime, we intend to modify our java code so that it dumps the compressed data in the event of a zip exception.
(Review ID: 34634)
======================================================================