Hi zlib 1.2.0.[4|5] and later have more "rigorous" distance-too-far boundary checks 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. This "invalid distance value" is exposed in JDK7, in which we upgraded the internal zlib from 1.1.3 to 1.2.3. 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 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). These two options are for different distance-too-far scenarios. The first one appears to be for cases that the compressed data stream permits the distance, but the zlib header restricting the window size does not, which is not our case. In our particular PNG case, the "distance" to look up is outside the window that has valid data. To allow such corrupted zip/png file to "work" as it did in previous (<7) releases, two things need to be done (1)define INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR (2)call the "undocumented" inflateUndermine(strm, 1) after each inflateInit/Reset invocation as in webrev http://cr.openjdk.java.net/~sherman/7148271/webrev While this indeed is a "regression", the question is do we really want this behavior (allow those corrupt zip/png files without throwing exception) to be the default behavior? A possible approach is to by default the j.u.zip.Inflater/PNGImageReader rejects such files (by throwing a zip exception, as the current JDK7 does) and to tolerate such files only with some -D flag, for example -Djava.util.zip.InflateAllowInvalidDistance. This definitely will be inconvenient for those who like the PNGImageReader to just work as it did in previous releases, but appears to be a more reasonable for me. Opinion? -Sherman
