[Zlib-devel] apparent 1.2.7 windowBits == 0 (autodetection) bug

[Greg Roelofs]

Someone just posted an error report to the libpng list about the following
icons triggering an "invalid distance too far back" error:

   http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.9/network-manager-applet-0.9.8.0.tar.xz

   -rw-rw-r-- 500/500         470 2009-12-23 10:30 network-manager-applet-0.9.8.0/icons/22/nm-signal-75.png
   -rw-rw-r-- 500/500         492 2009-12-23 10:30 network-manager-applet-0.9.8.0/icons/22/nm-signal-50.png
   -rw-rw-r-- 500/500         496 2009-12-23 10:30 network-manager-applet-0.9.8.0/icons/22/nm-signal-25.png
   -rw-rw-r-- 500/500         409 2009-12-23 10:30 network-manager-applet-0.9.8.0/icons/22/nm-signal-100.png
   -rw-rw-r-- 500/500         490 2009-12-23 10:30 network-manager-applet-0.9.8.0/icons/22/nm-signal-00.png

...but only with libpng 1.6.x.  All five files have windowBits == 9, and
passing that value to inflateInit2(), as pngcheck with zlib support does,
works fine.  But libpng uses the windowBits == 0 auto-detection feature,
and that breaks.  At the very least, zlib has a consistency bug--the streams
are either valid or they're not.  But it looks like the autodetection feature
may be broken.

Here's a sample of the output with explicit windowBits:

File: test/network-manager-applet-0.9.8.0--nm-signal-75.png (470 bytes)
  chunk IHDR at offset 0x0000c, length 13
    22 x 22 image, 32-bit RGB+alpha, non-interlaced
  chunk bKGD at offset 0x00025, length 6
    red = 0x00ff, green = 0x00ff, blue = 0x00ff
  chunk pHYs at offset 0x00037, length 9: 2835x2835 pixels/meter (72 dpi)
  chunk tIME at offset 0x0004c, length 7: 13 Oct 2004 22:51:00 UTC
  chunk tEXt at offset 0x0005f, length 29, keyword: Comment
  chunk IDAT at offset 0x00088, length 314
    zlib: deflated, 512-byte window, maximum compression

    GRR DEBUG:  calling inflateInit2() with zlib_windowbits = 9

    row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
      0 0 0 0 1 4 4 4 4 4 4 4 4 4 4 4 4 4 4 1 0 0 (22 out of 22)
  chunk IEND at offset 0x001ce, length 0
No errors detected in test/network-manager-applet-0.9.8.0--nm-signal-75.png (7 chunks, 75.7% compression).

Here's the same file with windowBits set to zero:

File: test/network-manager-applet-0.9.8.0--nm-signal-75.png (470 bytes)
  chunk IHDR at offset 0x0000c, length 13
    22 x 22 image, 32-bit RGB+alpha, non-interlaced
  chunk bKGD at offset 0x00025, length 6
    red = 0x00ff, green = 0x00ff, blue = 0x00ff
  chunk pHYs at offset 0x00037, length 9: 2835x2835 pixels/meter (72 dpi)
  chunk tIME at offset 0x0004c, length 7: 13 Oct 2004 22:51:00 UTC
  chunk tEXt at offset 0x0005f, length 29, keyword: Comment
  chunk IDAT at offset 0x00088, length 314
    zlib: deflated, 512-byte window, maximum compression

    GRR DEBUG:  calling inflateInit2() with zlib_windowbits = 0


    zlib: oops! can't initialize (error = -2)
    row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
     
    zlib: inflate error = -2 (stream error)
 (0 out of 22)
ERRORS DETECTED in test/network-manager-applet-0.9.8.0--nm-signal-75.png

(Note that pngcheck seems to get the error from inflateInit2() itself, while
libpng 1.6 apps appear to get it from inflate().  I'm not sure what to make
of that, but reportedly libpng calls inflateReset2() directly.  Quick code
inspection suggests that shouldn't make a difference, though.)

Greg