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

REGRESSION with PNG Image loading

    Details

      Description

      The follow simple sample work with Java 6 and throw the follow Exception with Java 7.
       

      import java.io.FileInputStream;

      import java.io.FileNotFoundException;

      import java.io.IOException;

       

      import javax.imageio.ImageIO;

       

      public class TestImageIO {

       

          public static void main( String[] args ) throws FileNotFoundException, IOException {

              ImageIO.read( new FileInputStream( "CorruptImage.png" ) );

          }

      }

       

       

      Exception in thread "main" javax.imageio.IIOException: Error reading PNG image data

            at com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1308)

            at com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1577)

            at javax.imageio.ImageIO.read(ImageIO.java:1448)

            at javax.imageio.ImageIO.read(ImageIO.java:1352)

            at TestImageIO.main(TestImageIO.java:10)

      Caused by: java.util.zip.ZipException: invalid distance too far back

            at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)

            at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)

            at java.io.BufferedInputStream.read(BufferedInputStream.java:254)

            at java.io.FilterInputStream.read(FilterInputStream.java:83)

            at com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNGImageReader.java:1085)

            at com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PNGImageReader.java:1196)

            at com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1301)

            ... 4 more

        Issue Links

          Activity

          Hide
          bae Andrew Brygin added a comment -
          BT2:EVALUATION

          Attached testcase demonstrates that the problem is caused by a change in
          behavior of java.util.zip classes: the same chunk of compressed data is succesfully decoded by jdk6u32, but causes the exception by jdk7u4.
          So, I am transferring this CR to java.util.zip category for further investigation.

          C:\work\bugs\7148271>c:\work\slash_java\re\jdk\6u32\windows-i586\bin\java -showversion SimpleTest png_2249973499429902101.zip
          java version "1.6.0_32-ea"
          Java(TM) SE Runtime Environment (build 1.6.0_32-ea-b02)
          Java HotSpot(TM) Client VM (build 20.7-b01, mixed mode)

          File to test: png_2249973499429902101.zip
          Filter: 0

          C:\work\bugs\7148271>c:\work\slash_java\re\jdk\1.7.0\promoted\latest\binaries\windows-i586\bin\java -showversion SimpleTest png_2249973499429902101.zip
          java version "1.7.0_04-ea"
          Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b10)
          Java HotSpot(TM) Client VM (build 23.0-b12, mixed mode)

          File to test: png_2249973499429902101.zip
          Exception in thread "main" java.util.zip.ZipException: invalid distance too far
          back
                  at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
                  at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
                  at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
                  at java.io.FilterInputStream.read(FilterInputStream.java:83)
                  at SimpleTest.main(SimpleTest.java:21)
          Show
          bae Andrew Brygin added a comment - BT2:EVALUATION Attached testcase demonstrates that the problem is caused by a change in behavior of java.util.zip classes: the same chunk of compressed data is succesfully decoded by jdk6u32, but causes the exception by jdk7u4. So, I am transferring this CR to java.util.zip category for further investigation. C:\work\bugs\7148271>c:\work\slash_java\re\jdk\6u32\windows-i586\bin\java -showversion SimpleTest png_2249973499429902101.zip java version "1.6.0_32-ea" Java(TM) SE Runtime Environment (build 1.6.0_32-ea-b02) Java HotSpot(TM) Client VM (build 20.7-b01, mixed mode) File to test: png_2249973499429902101.zip Filter: 0 C:\work\bugs\7148271>c:\work\slash_java\re\jdk\1.7.0\promoted\latest\binaries\windows-i586\bin\java -showversion SimpleTest png_2249973499429902101.zip java version "1.7.0_04-ea" Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b10) Java HotSpot(TM) Client VM (build 23.0-b12, mixed mode) File to test: png_2249973499429902101.zip Exception in thread "main" java.util.zip.ZipException: invalid distance too far back         at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)         at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)         at java.io.BufferedInputStream.read(BufferedInputStream.java:254)         at java.io.FilterInputStream.read(FilterInputStream.java:83)         at SimpleTest.main(SimpleTest.java:21)
          Hide
          alanb Alan Bateman added a comment -
          BT2:EVALUATION

          The zip file with the PNG appears to be corrupt, in which case the zip APIs are correct to throw an exception. Older version of zlib may be less tolerant to corrupt zip files.

          Here's what the native zip tool reports:

          $ unzip -t png_2249973499429902101.zip
          Archive: png_2249973499429902101.zip
            End-of-central-directory signature not found. Either this file is not
            a zipfile, or it constitutes one disk of a multi-part archive. In the
            latter case the central directory and zipfile comment will be found on
            the last disk(s) of this archive.
          unzip: cannot find zipfile directory in one of png_2249973499429902101.zip or
                  png_2249973499429902101.zip.zip, and cannot find png_2249973499429902101.zip.ZIP, period.

          For now I am marking this bug as incomplete. It would be great if the submitter could double check the zip file that they have in case it got corrupted in transit to the bug database.
          Show
          alanb Alan Bateman added a comment - BT2:EVALUATION The zip file with the PNG appears to be corrupt, in which case the zip APIs are correct to throw an exception. Older version of zlib may be less tolerant to corrupt zip files. Here's what the native zip tool reports: $ unzip -t png_2249973499429902101.zip Archive: png_2249973499429902101.zip   End-of-central-directory signature not found. Either this file is not   a zipfile, or it constitutes one disk of a multi-part archive. In the   latter case the central directory and zipfile comment will be found on   the last disk(s) of this archive. unzip: cannot find zipfile directory in one of png_2249973499429902101.zip or         png_2249973499429902101.zip.zip, and cannot find png_2249973499429902101.zip.ZIP, period. For now I am marking this bug as incomplete. It would be great if the submitter could double check the zip file that they have in case it got corrupted in transit to the bug database.
          Hide
          bae Andrew Brygin added a comment -
          BT2:EVALUATION

          I have re-attached the data file to CR: png_2249973499429902101.bin.
          Now it seems to be fine, at leas I was able to download the data file
          form bugster and reproduce the probelm.
          Show
          bae Andrew Brygin added a comment - BT2:EVALUATION I have re-attached the data file to CR: png_2249973499429902101.bin. Now it seems to be fine, at leas I was able to download the data file form bugster and reproduce the probelm.
          Hide
          sherman Xueming Shen added a comment -
          BT2:EVALUATION

          zlib 1.2.0.[4|5] and later have more "rigorous" boundary checks for distance-too-far than previous versions. The PNG image file used in this case appears to be one of those "corrupted" files that have incorrect "distance" value in its compressed image data. A google search with "zlib png distance too far" suggests Java is not the only runtime/app that has this particular issue. Two compile options INFLATE_STRICT and INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR (for different cases) have been introduced in 1.2.3.4 to disable the "rigorous" check and permit those invalid distance-too-far streams. In java we are currently not defining any of them (as most of the zlib configuration does).

          In this particular case, a combination of
          (1) define INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR
          (2) call the "undocumented" inflateUndermine(strm, 1) after each inflateInit/Reset invocation

          can allow invalid distances for those corrupted zip/png file.

          The question is do we really want this behavior (allow those corrupt zip/png file without throwing exception) by default?
          Show
          sherman Xueming Shen added a comment - BT2:EVALUATION zlib 1.2.0.[4|5] and later have more "rigorous" boundary checks for distance-too-far than previous versions. The PNG image file used in this case appears to be one of those "corrupted" files that have incorrect "distance" value in its compressed image data. A google search with "zlib png distance too far" suggests Java is not the only runtime/app that has this particular issue. Two compile options INFLATE_STRICT and INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR (for different cases) have been introduced in 1.2.3.4 to disable the "rigorous" check and permit those invalid distance-too-far streams. In java we are currently not defining any of them (as most of the zlib configuration does). In this particular case, a combination of (1) define INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR (2) call the "undocumented" inflateUndermine(strm, 1) after each inflateInit/Reset invocation can allow invalid distances for those corrupted zip/png file. The question is do we really want this behavior (allow those corrupt zip/png file without throwing exception) by default?
          Hide
          sherman Xueming Shen added a comment -
          Closed as "won't fix", for now. Please re-open and escalate if there is indeed business case that requires the support for this type of "known" corrupt PNG image file.
          Show
          sherman Xueming Shen added a comment - Closed as "won't fix", for now. Please re-open and escalate if there is indeed business case that requires the support for this type of "known" corrupt PNG image file.

            People

            • Assignee:
              sherman Xueming Shen
              Reporter:
              tyao Ting-Yun Ingrid Yao (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: