283214 - Zlib decoding of PNG isn't as forgiving as 1.8a1

Status: RESOLVED WONTFIX

(Core :: Graphics: ImageLib, defect)

Description

[Dan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050222 MultiZilla/1.7.0.2d Mnenhy/0.7.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050222 MultiZilla/1.7.0.2d Mnenhy/0.7.1

Mozilla 1.7x and Firefox 1.0, as well as IE6 and Opera deocde these pngs just
fine, but I am unable to view the imagines in 1.8a6 and the nightlies since. I'm
not sure how back far it goes, I just moved to the 1.8 trunk recently. None of
the PNGs generated by Audio Rightmark will decode properly in 1.8x, only an
error saying the image is corrupted.

Reproducible: Always

Steps to Reproduce:
1. go to http://audio.rightmark.org/test/audiotrak-prodigy192-1644.html
2. 
3.

Actual Results:  
none of the PNG images load. right clicking on the png and viewing them gives
the error that they are corrupted

Expected Results:  
display the PNG correctly.

Using rightmark on my computer I can open the images in 1.8x by resaving them in
photoshop. This suggests that either libpng might've been updated in 1.8x or
there's a PNG regression. If it's great to try to go for the latest and great,
but the fact that other browsers decode the images just fine makes this a nuisance.

Comment 1

[OstGote!]

Confirming, FF10, FF 1.0.1 20050216, Mozilla 1.7.5, Mozilla 1.8a1  shows the PNG
but not Mozilla 1.8a2, Mozilla 1.8a3, Mozilla 1.8b2 2005022104 on WinNT4.
http://audio.rightmark.org/test/audiotrak-prodigy192-1644/noise.png

So it regresses between the 1.8a1 and 1.8a2 release of Mozilla.

Comment 2

[Glenn Randers-Pehrson]

pngcrush and graphicsmagick both reject the images with a zlib error
message.  It is probably related to the recent update of zlib to version
1.2.1 or 1.2.2, which have more rigorous checking for distance-too-far errors.

Comment 3

[Glenn Randers-Pehrson]

Taking bug.  The zlib developers are looking at this.  The previous zlib version
was reading out-of-bounds memory.  When that was fixed (in 1.2.1 and 1.2.2) the
error messages started appearing.  We agree that zlib should be more forgiving
and will probably supply zeroes whenever this uninitialized memory is read, and
issue a warning.  I'll relay whatever patch comes out of zlib devel.

Comment 4

[Glenn Randers-Pehrson]

Changing summary to mention "zlib"
Gerard Juyn has verified that MNG decoding is affected similarly.

Comment 5

[Glenn Randers-Pehrson]

No surprise; Firefox 1.0.1 Gecko 20050225 (amano) does not exhibit this bug.

Comment 6

[Josh Birnbaum]

*** Bug 298651 has been marked as a duplicate of this bug. ***

Comment 7

[Glenn Randers-Pehrson]

Checkin of the patch for bug #301646 landed zlib-1.2.3 and fixed this bug.
Both Mozilla-1.7.12 and Firefox-1.0.7 display the test images properly on a
windows-xp platform.

Comment 8

[Dan]

yup works in 1.7.12, but still doesn't work in firefox 1.5beta and seamonkey
20050926 :(

Comment 9

[Dan]

as far as I can tell zlib 1.2.3 was not checked into the 1.7.x branch. it still
uses zlib 1.1.4 which isn't affected by this bug. testing under
seamonkey1.0a/linux and seamonkey1.0a/windows still shows that zlib 1.2.3 does
not fix this problem. I'd like to reopen this bug tomorrow if there's no
objection. am I mistaken, and there's a build somewhere where it works?

Comment 10

[Dan]

tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050930 SeaMonkey/1.1a
test case still results in "the image (uri) cannot be displayed because it
contains errors"

Comment 11

[Daniel Ovsiannikov]

May this bug be a blocker for 1.5RC1? I frequently visit iXBT & RightMark. I hope I will be able to do so with Firefox, not Opera. 

Comment 12

[Jon Henry]

Asking for blocking on Dan's behalf, but I imagine drivers aren't interested in big changes this late unfortunately.

FWIW, bug 301646 does have a patch with a=bsmedberg on it that would presumably fix this.

Comment 13

[Dan]

I think the problem is still in zlib. Testing under linux (I believe most browsers are linking to a shared zlib lib) with zlib 1.2.3 shows that it's still a problem in zlib. Even firefox 1.0.7 and Opera 8.5 were unable to display the images in the test url.

Comment 14

[Mike Schroepfer]

Closing out for rc1 at this time.  Since the image files are invalid and the issue is in zlib library (due to security fixes) - we are not going to get this resolved in 1.5.

Comment 15

[Hermann Schwab]

*** Bug 325067 has been marked as a duplicate of this bug. ***

Comment 16

[Glenn Randers-Pehrson]

*** Bug 327270 has been marked as a duplicate of this bug. ***

Comment 17

[Glenn Randers-Pehrson]

*** Bug 347328 has been marked as a duplicate of this bug. ***

Comment 18

[Nathan Lewis]

I came across this thread while investigation a problem using zlib 1.2.3 to inflate MSZIP compressed data from CAB files.  So while the following may or may not be directly related, it may (hopefully) point someone in the right direction.

My solution to the "too far back" error was inspired by the solution found by the KCabinet developer, Brad Hards.  I'm quoting part of his comments from http://www.kdedevelopers.org/node/3181 here in case it disappears from the web:

"In the end, I asked the zlib authors. Mark Adler...came back overnight with the right answer (despite never having tried it): [use] the previous 32K block as a dictionary. You can use inflateSetDictionary() to set the dictionary for the next block before decompressing."

"Essentially the sequence that works for me is:"

   inflateInit2( streamState, -MAX_WBITS );
   for each block:
      parse the header (including the CK prefix on the data);
      read the compressed data, and add that [to] the streamState;
      inflate( streamState, Z_SYNC_FLUSH );
      copy the decompressed data to the output buffer;
      inflateReset( streamState );
      inflateSetDictionary( streamState, decompressedData, decompressedDataSize );
   inflateEnd( streamState );


This worked great for me.  All credit goes to Brad Hards and Mark Adler if it works for PNG decoding as well.  If not, blame me.  :)

Comment 19

[Nathan Lewis]

"while investigation a problem"...?  Ugh.  Ignore that typo, please. :P

Comment 20

[Glenn Randers-Pehrson]

There was a workaround provided by Mark Adler in libz-1.2.3.3 over a year ago but has not been publicly released as libz-1.2.4 yet.  The workaround is rather ugly, and requires a special libz build.  The software that creates the bad images was repaired long ago (2002?) but some people may still be using it.

Comment 21

[Benoit Girard (:BenWa)]

These images don't work on chrome and safari. I'm assuming these images have errors in them as I can't get them to decode on OS X under any program. Please reopen if you think this is still an issue.