JDK-7021870 : GzipInputStream closes underlying stream during reading
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 6u24
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2011-02-23
  • Updated: 2014-09-30
  • Resolved: 2013-05-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b91Fixed
Related Reports
Relates :  
Relates :  
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.

Comments
verified in b94
18-06-2013

The fix that was pushed to jdk8 is a workaround and doesn't get to the root of the issue. We may need to open a new bug to do a more complete fix. Please do not back-port this issue to jdk7u without further discussion on the core-libs-dev list.
12-05-2013

Okay, I've set the fixVersion to 8 and we should fix the issue there first. Backport issues can be created if the fix is going into other releases.
10-05-2013

The labels are 7-open and 8-open, not 7-na, 8-na. I set them to indicate that the issue is still there for both 7 and 8.
10-05-2013