94183 - Decoding of (possibly flawed) PNG images causes eventual crash

Status: RESOLVED DUPLICATE of bug 93658

(Core :: Graphics: ImageLib, defect)

Description

[Ray Whitmer]

Some with PNG's in their web pages might call this critical, since it crashes.

To reproduce this I retrieve the URL (my own):

http://www.xmission.com/~ray/NaturalCoordinateSystem.html

This usually crashes immediately, but sometimes it waits until I retrieve other
things later.

I have submitted dozens of tracebacks in the past exhibiting this. I will be in
Mountain View through Friday, August 10, 2001 (or the week of the first Monday
in any Month), so you can watch it happen on my machine. 

I type in the URL, and if I am in the debug build, I get complaints about
"libpng error: Extra compression data", once for each graphic in the document,
and then Netscape 6.1 or the tip build for Mozilla crashes.

Others have successfully viewed the document in a windows build. If I type in
the URLs of the PNG files within the document, I successfully display the first
few, and then I get a crash when I didn't even type anything new.

I believe that there is something about these particular PNG files that may not
be completely standard. They are created by the free ray tracing program POV Ray
from fairly simple description files. But the Linux ImageMagick "convert"
command refuses to process them making a complaint similar to the one raised by
Netscape:  

"libpng-1.0.9 error: Too many IDAT's found convert: Too many IDAT's found [No
such file or directory]"

But Netscape 4.7 displayed them with no error, and sometimes Mozilla or Netscape
6.x displays them and it causes an asynchronous crash later or not at all.  
Displaying these graphics should not crash.

Here is the debugger stack at one of the crashes using a build of source I
pulled down last night (August 6, 2001):

#0  0x4060f966 in _setjmp () from /lib/libc.so.6
#1  0x42133eb7 in ReadDataOut (in=0x86ce080, closure=0x87c8d38,
    fromRawSegment=0x88257a0
"éFss³N§\223·PhôÑfgg].×ùóçÏ\2349311áv¹\212\216\036}ÊãYØåaµb6ÛÅ?\224\bU\213.àεÁh\024b \rá9Ä=\220\032\177\bÓ\210ø\e\004ùÃEü\004\003^¥\002q8¯\021\233¹¹#yy¾ÊÊ\213ÅÅwµ¶fÖ××\227\225\225eee­]»V\213\217677çv»ß|óÍW~üãÝo¿ý\204\034\fP¦Å))W\222Åî\212Ipðg\214 ÒW1ü#\222¼\2141®\020f#]¿¡C^\222\232\020ÁÀU¸\026\235×\210ÍôtWNÎpC\203³¶v®¢\"³"...,
toOffset=0, count=1516,
    writeCount=0xbfffee2c) at nsPNGDecoder.cpp:143
#2  0x401cbf99 in nsInputStreamTee::WriteSegmentFun (in=0x86ce080,
    closure=0x872ac60,
    fromSegment=0x88257a0
"éFss³N§\223·PhôÑfgg].×ùóçÏ\2349311áv¹\212\216\036}ÊãYØåaµb6ÛÅ?\224\bU\213.àεÁh\024b \rá9Ä=\220\032\177\bÓ\210ø\e\004ùÃEü\004\003^¥\002q8¯\021\233¹¹#yy¾ÊÊ\213ÅÅwµ¶fÖ××\227\225\225eee­]»V\213\217677çv»ß|óÍW~üãÝo¿ý\204\034\fP¦Å))W\222Åî\212Ipðg\214 ÒW1ü#\222¼\2141®\020f#]¿¡C^\222\232\020ÁÀU¸\026\235×\210ÍôtWNÎpC\203³¶v®¢\"³"...,
offset=0, count=1516,
    writeCount=0xbfffee2c) at nsInputStreamTee.cpp:81
#3  0x401d0403 in nsPipe::nsPipeInputStream::ReadSegments (this=0x86ce080,
    writer=0x401cbf60 <nsInputStreamTee::WriteSegmentFun(nsIInputStream *, void
*, char const *, unsigned int, unsigned int, unsigned int *)>,
    closure=0x872ac60, count=1516, readCount=0xbfffef1c) at nsPipe2.cpp:411
#4  0x401cc604 in nsInputStreamTee::ReadSegments (this=0x872ac60,
    writer=0x42133e90 <ReadDataOut(nsIInputStream *, void *, char const *,
unsigned int, unsigned int, unsigned int *)>, closure=0x87c8d38, count=1516,
    bytesRead=0xbfffef1c) at nsInputStreamTee.cpp:137
#5  0x42133f6d in nsPNGDecoder::WriteFrom (this=0x87c8d38, inStr=0x872ac60,
    count=1516, _retval=0xbfffef1c) at nsPNGDecoder.cpp:163
#6  0x415501bf in imgRequest::OnDataAvailable (this=0x87cdd80,
    aRequest=0x877a198, ctxt=0x0, inStr=0x872ac60, sourceOffset=16384,
    count=1516) at imgRequest.cpp:739
#7  0x4154d276 in ProxyListener::OnDataAvailable (this=0x87c3b58,
    aRequest=0x877a198, ctxt=0x0, inStr=0x872ac60, sourceOffset=16384,
    count=1516) at imgLoader.cpp:401
#8  0x40b2acf4 in nsStreamListenerTee::OnDataAvailable (this=0x87c8c28,
    request=0x877a198, context=0x0, input=0x86ce080, offset=16384, count=1516)
    at nsStreamListenerTee.cpp:56
#9  0x40b6252e in nsHttpChannel::OnDataAvailable (this=0x877a198,
    request=0x83ed878, ctxt=0x0, input=0x86ce080, offset=16384, count=1516)
    at nsHttpChannel.cpp:2174
#10 0x40b1176d in nsOnDataAvailableEvent::HandleEvent (this=0x8950948)
    at nsStreamListenerProxy.cpp:178
#11 0x40b10a94 in nsARequestObserverEvent::HandlePLEvent (plev=0x8950948)
    at nsRequestObserverProxy.cpp:63
#12 0x401ee5cc in PL_HandleEvent (self=0x8950948) at plevent.c:590
#13 0x401ee3b9 in PL_ProcessPendingEvents (self=0x80baa28) at plevent.c:520
#14 0x401f0850 in nsEventQueueImpl::ProcessPendingEvents (this=0x80baa00)
    at nsEventQueue.cpp:374
#15 0x40d07b34 in event_processor_callback (data=0x80baa00, source=7,
    condition=GDK_INPUT_READ) at nsAppShell.cpp:168
#16 0x40d076b3 in our_gdk_io_invoke (source=0x8248038, condition=G_IO_IN,
    data=0x8248028) at nsAppShell.cpp:61

Comment 1

[Ray Whitmer]

Sometimes I get a bizarre alternative behavior: Some pictures do not appear and
instead their alternative text is displayed.

Comment 2

[tenthumbs]

FWIW, most of the PNG's do have an extra IDAT chunk. A typical example 
is:

File: caltrops.png (5456 bytes)
  chunk IHDR at offset 0x0000c, length 13
    160 x 120 image, 24-bit RGB, non-interlaced
  chunk gAMA at offset 0x00025, length 4: 0.45455
  chunk sBIT at offset 0x00035, length 3: red = 8 green = 8 blue = 8
  chunk IDAT at offset 0x00044, length 1179
    zlib:  deflated, 32K window, default compression
    zlib line filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
      0 0 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 4 4 (40 out of 120)
  chunk IDAT at offset 0x004eb, length 2899
    zlib line filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
      4 4 4 4 4 4 4 4 4 4 2 2 2 2 4 2 2 2 2 2 2 2 2 2 2
      2 4 4 3 3 3 1 1 4 4 4 4 4 4 4 (80 out of 120)
  chunk IDAT at offset 0x0104a, length 623
    zlib line filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 2 2 2 2 2
      2 2 0 2 0 0 3 3 2 3 0 0 0 0 0 (120 out of 120)
  chunk IDAT at offset 0x012c5, length 631
  chunk IEND at offset 0x01548, length 0

Note the last IDAT follows the real image. Libpng treats this as an 
error. Imagemagick, and some other packages, treat this as recoverable 
error because the entire image is intact.

Comment 3

[[e-mail]]

The broken PNGs are a known bug in Povray. You are right of course that broken
images (all too common on the web) must not crash the browser.
Adding crash keyword (since I have no reason to doubt the reporters word that
this crashes Mozilla)

The stack trace shows Libc in setjmp() and I suspect that's a problem.
libpng will longjmp() back to a jump buffer setup by Mozilla when it encounters
a fatal error. If some or all of the code in Mozilla is not longjmp() safe then
this will cause crashes or other problems.

I could be barking up the wrong tree, but this has definitely caused problems
for other applications in the past.

Comment 4

[tenthumbs]

GCC does *not* save registers across a longjmp (it's not required to) so 
any variable that's been optimized into a register will contain garbage. 
The most likely culprit is this line in ReadDataOut:
 nsPNGDecoder *decoder = NS_STATIC_CAST(nsPNGDecoder*, closure);
That should probably be
 nsPNGDecoder * volatile decoder = ...

GCC usually issues warnings about this and they should never be ignored.

Comment 5

[pbergsag]

I wonder if I am experiencing the same bug. I am using a Apple G3-350 (B/W)
using Mac OS 8.6. I am testing Mozilla Build ID 2001111608. Here is my test case: 
1.  Go to bug 108666 (in bugzilla) and attempt to view the two .png attachments
titled "Screenshot" and "Screen sot of JS Console error".

2.  The first attachment "Screenshot" brings up a blank screen and then    
crahses into the debugger Macsbug.

3. The second attachment shows its image for a second before the browser crashes.

I have tested with the Quicktime plug-in set to display .pgn and still
experience the crash. I also was able to open a .png file stred on my hard drive
with Mozilla. 

I will attach a Macsbug stack trace. Should this bug be updated to include the
Mac OS?

Comment 6

[pbergsag]

Attachment: This MacsBug stack trace was generated with Quicktime set to display .png

Comment 7

[Matthias Versen [:Matti]]

dupe of bug 89595 ?

Comment 8

[Nivedita (gone)]

*** This bug has been marked as a duplicate of 93658 ***