CR 7148271 REGESSION with PNG Image loading
Xueming Shen
xueming.shen at oracle.com
Tue Mar 13 19:03:08 UTC 2012
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
More information about the core-libs-dev
mailing list