Details
-
Bug
-
Resolution: Fixed
-
P3
-
6u24
-
b91
-
x86
-
linux
-
Verified
Description
FULL PRODUCT VERSION :
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 5.2.3790]
Linux 64 bits
A DESCRIPTION OF THE PROBLEM :
It used to work fine in jdk1.6.0_20
It stopped working between then and jdk 1.6.0_24
The GZIPInputStream reading causes the underlying stream to be closed.
That stream was not opened by GZIPInputStream , thus it should not be closed either. For us, this breaks the communication over a socket input stream.
We have a ZipInputStream on which we iterate .getNextEntry().
Instead of returning null, it throws an IOException for the stream closed (coming from zipinputstream.ensureOpen()).
Examining the usage of the zipinputstream, we do wrap a GZIPInputStream on it.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Make a zip file, made of gzipped file entries.
Try to read it (with only one FileInputStream instance of course...).
In a nutshell:
ZipInputStream zis = new ZipInputStream(somefileinputstream);
while( zis.getNextEntry() !=null) {
InputStream gis = new GZIPInputStream(ziz, 8192);
//read from gis until dry
}
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the somefileinputstream should not be closed, in case I have other things to read in it.
ACTUAL -
The zis.getNextEntry() throws IOException.
I proxied and breakpointed the somefileinputstream.close(): this is the origin of the closure:
[....]
java.io.PushbackInputStream.close() line: 358 [local variables unavailable]
java.util.zip.ZipInputStream(java.util.zip.InflaterInputStream).close() line: 210
java.util.zip.ZipInputStream.close() line: 226
java.io.SequenceInputStream.nextStream() line: 89 [local variables unavailable]
java.io.SequenceInputStream.read() line: 151 [local variables unavailable]
java.io.SequenceInputStream.read() line: 152
java.util.zip.CheckedInputStream.read() line: 42 [local variables unavailable]
java.util.zip.GZIPInputStream.readUByte(java.io.InputStream) line: 247
java.util.zip.GZIPInputStream.readUShort(java.io.InputStream) line: 239
java.util.zip.GZIPInputStream.readHeader(java.io.InputStream) line: 142
java.util.zip.GZIPInputStream.readTrailer() line: 213
java.util.zip.GZIPInputStream.read(byte[], int, int) line: 94
java.util.zip.GZIPInputStream(java.io.FilterInputStream).read(byte[]) line:
[...]
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
One has to proxy the underlying stream and intercept .close() calls.
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 5.2.3790]
Linux 64 bits
A DESCRIPTION OF THE PROBLEM :
It used to work fine in jdk1.6.0_20
It stopped working between then and jdk 1.6.0_24
The GZIPInputStream reading causes the underlying stream to be closed.
That stream was not opened by GZIPInputStream , thus it should not be closed either. For us, this breaks the communication over a socket input stream.
We have a ZipInputStream on which we iterate .getNextEntry().
Instead of returning null, it throws an IOException for the stream closed (coming from zipinputstream.ensureOpen()).
Examining the usage of the zipinputstream, we do wrap a GZIPInputStream on it.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Make a zip file, made of gzipped file entries.
Try to read it (with only one FileInputStream instance of course...).
In a nutshell:
ZipInputStream zis = new ZipInputStream(somefileinputstream);
while( zis.getNextEntry() !=null) {
InputStream gis = new GZIPInputStream(ziz, 8192);
//read from gis until dry
}
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the somefileinputstream should not be closed, in case I have other things to read in it.
ACTUAL -
The zis.getNextEntry() throws IOException.
I proxied and breakpointed the somefileinputstream.close(): this is the origin of the closure:
[....]
java.io.PushbackInputStream.close() line: 358 [local variables unavailable]
java.util.zip.ZipInputStream(java.util.zip.InflaterInputStream).close() line: 210
java.util.zip.ZipInputStream.close() line: 226
java.io.SequenceInputStream.nextStream() line: 89 [local variables unavailable]
java.io.SequenceInputStream.read() line: 151 [local variables unavailable]
java.io.SequenceInputStream.read() line: 152
java.util.zip.CheckedInputStream.read() line: 42 [local variables unavailable]
java.util.zip.GZIPInputStream.readUByte(java.io.InputStream) line: 247
java.util.zip.GZIPInputStream.readUShort(java.io.InputStream) line: 239
java.util.zip.GZIPInputStream.readHeader(java.io.InputStream) line: 142
java.util.zip.GZIPInputStream.readTrailer() line: 213
java.util.zip.GZIPInputStream.read(byte[], int, int) line: 94
java.util.zip.GZIPInputStream(java.io.FilterInputStream).read(byte[]) line:
[...]
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
One has to proxy the underlying stream and intercept .close() calls.
Attachments
Issue Links
- relates to
-
JDK-4691425 GZIPInputStream fails to read concatenated .gz files
- Closed
-
JDK-7036144 GZIPInputStream readTrailer uses faulty available() test for end-of-stream
- Closed