Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7021870

GzipInputStream closes underlying stream during reading

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 6u24
    • Fix Version/s: 8
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b91
    • CPU:
      x86
    • OS:
      linux
    • Verification:
      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                igerasim Ivan Gerasimov
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: