93658 - Page crashes mozilla, but only over the network

Status: VERIFIED DUPLICATE of bug 89595

(Core :: Graphics: ImageLib, defect)

Description

[Ken Harris]

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19 i686)
BuildID:    2001080221

This page crashes mozilla before anything is displayed.  I
downloaded the HTML with another program to see what might
be causing the crash, but loading it from a local HTML file
works fine.

It's the "Summaries by Architecture" link on the page
http://gcc.gnu.org/benchresults/

Reproducible: Always
Steps to Reproduce:
1. Go to http://gcc.gnu.org/benchresults/
2. Click on "Summaries by Architecture"


Actual Results:  Crashes moz before anything is displayed.

Expected Results:  (...)

Comment 1

[Con Kolivas]

Confirmed on linux 0.9.3 with talkback build
Talkback ID: TB33789072X

Comment 2

[Asa Dotzler [:asa]]

Incident ID 33789072
Stack Signature libc.so.6 + 0x2ce54 (0x404e1e54) ec83acd8
Bug ID
Trigger Time 2001-08-06 07:34:22
Email Address [e-mail]
User Comments Click on "Summaries by Architecture"
Build ID 2001080104
Product ID MozillaTrunk
Platform ID LinuxIntel
Stack Trace
libc.so.6 + 0x2ce54 (0x404e1e54)
nsInputStreamTee::WriteSegmentFun()
ReadSegments()
nsInputStreamTee::ReadSegments()
nsPNGDecoder::WriteFrom()
imgRequest::OnDataAvailable()
ProxyListener::OnDataAvailable()
nsStreamListenerTee::OnDataAvailable()
nsHttpChannel::OnDataAvailable()
nsOnDataAvailableEvent::HandleEvent()
nsARequestObserverEvent::HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke() 

Comment 3

[timeless]

does it crash mozilla if image loading is off ;-?

Comment 4

[Ken Harris]

In this day of ultra-high-speed everything, I didn't know
that was still an option.  :-)

[e-mail] has enlightened me.  To summarize my findings
for the record: The page loads fine with image loading off,
*but* I can see the image in Composer, and if I point Mozilla
directly to that image, that works too.  (Strange.)

Comment 5

[Diego Biurrun]

Confirmed on linux 0.9.3 as well as 2001081408, talkback ID TB34115004K

--> NEW

Comment 6

[Terri Preston]

I am not seeing this behavior on linux build 2001110808, marking wfm, please try
with a newer build and if you still see this behavior, reopen

Comment 7

[Diego Biurrun]

Still crashing with 0.9.5 and 2001110612 ---> REOPENED

Comment 8

[Diego Biurrun]

TB37761710Q
TB37761704Y

No crash with images disabled

Comment 9

[Diego Biurrun]

Still a problem with milestone 0.9.6.

TB38412545W

Stephen, could you be so kind and retrieve the talkback data? Thanks.

Comment 10

[[e-mail] (gone - use [e-mail] instead)]

Stack Signature  libc.so.6 + 0x2d364 (0x404b3364) cab75d93
Bug ID
Trigger Time 2001-11-23 08:37:34
Email Address [e-mail]
URL visited http://gcc.gnu.org/benchresults/aov.html
User Comments Rechecking bug 93658 .. still there.
Build ID 2001112012
Product ID MozillaBranch
Platform
Operating System LinuxIntel
Module
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Stack Trace
libc.so.6 + 0x2d364 (0x404b3364)
nsInputStreamTee::WriteSegmentFun()
ReadSegments()
nsInputStreamTee::ReadSegments()
nsPNGDecoder::WriteFrom()
imgRequest::OnDataAvailable()
ProxyListener::OnDataAvailable()
nsStreamListenerTee::OnDataAvailable()
nsHttpChannel::OnDataAvailable()
nsOnDataAvailableEvent::HandleEvent()
nsARequestObserverEvent::HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xec80 (0x4035ec80)
libglib-1.2.so.0 + 0x10348 (0x40360348)
libglib-1.2.so.0 + 0x10953 (0x40360953)
libglib-1.2.so.0 + 0x10aec (0x40360aec)
libgtk-1.2.so.0 + 0x8cff7 (0x4027fff7)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1d65f (0x404a365f) 

Comment 11

[Diego Biurrun]

Just crashed again with 2001121606.  I get the following message on the console:

libpng error: Decompression Error
/usr/local/mozilla/nightly/run-mozilla.sh: line 72:  5260 Segmentation fault   
  $prog ${1+"$@"}

Comment 12

[Diego Biurrun]

still a problem in 0.9.7 - TB784428Q

Comment 13

[Nivedita (gone)]

Attachment: patch file fixing the crash for a corrupted png

The carsh occurs because the error encountered in PNGDecoder class in not
propogated back to the imgRequest class.

In this case, the libpng encounters a "Decompression Error", hence calls
png_destroy_read_struct to release all memory used by the read operation and
returns NS_ERROR_FAILURE to PipeInputStream ReadSegments function, which needs
to propagate up to imgRequest class. But this error does not get propogated to
the imgRequest class, because nsPipeInputStream manipulates the return value as
NS_OK. Hence, in the next Read operation performed for this image, crash is
encountered when access is made to the structures which png_destroy_read_struct
has already released.

Change is made in ReadSegments function call of nsPipeInputStream, to propagate
error.

Comment 14

[Nivedita (gone)]

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

Comment 15

[Diego Biurrun]

Just tried the patch - no crash.  The following message gets printed to the console:

libpng error: Decompression Error

The image is not rendered, 4.77 has no problems.  Should I file a separate bug
for this?  Is this a known problem?

Comment 16

[Darin Fisher]

nivedita: the problem here is that by design ReadSegments does not need to honor
error codes from it's writer function.  exceptions are intentionally masked. 
this may seem odd, but it's a requirement for other reasons... 

  ReadSegments(writer, count) - give as much data as possible (not exceeding
                                count  bytes) to the writer.  if the writer
                                fails at some point to accept data, return 
                                the count successfully given.

in the case of a pipe, data is stored in segments.  so, the pipe starts by
giving data from the first segment to its writer.  if the writer accepts that,
then proceed to the next segment (if not exceeding count).  if the writer fails
to accept data from the second segment (for any reason), the pipe's ReadSegments
returns what was successfully given.

this means that your nsWriteSegmentFun implementation should catch errors and
store them someplace so that the caller of ReadSegments can check for such
exceptions.

Comment 17

[Nivedita (gone)]

Stuart, Darin:
To have imgRequest handle the errors of the decoder class, we could have a 
attribute mErrorStatus defined in the imgIDecoder and call set of mErrorStatus 
to true in an error case. The imgRequest class could verify the error status by 
calling getter of mErrorStatus in addition to the return value from the 
ReadSegments. mErrorStatus could have a default value as FALSE. 

Can you please convey your thoughts on above.

Comment 18

[Stuart Parmenter]

rpotts, darin, care to look at this?

Comment 19

[Darin Fisher]

i'd suggest using a nsresult for the status, like so:

  interface imgIDecoder {
    // ...
    readonly attribute nsresult status;
    // ...
  };

Comment 20

[Nivedita (gone)]

Attachment: patch file fixing the crash for a corrupted png

setting errorstate variable as true on encountering an error from the pnglib.
Making check for errorstate before processing data.

Comment 21

[Nivedita (gone)]

Comment on attachment 68519 [details] [diff] [review]
patch file fixing the crash for a corrupted png

needs work

Comment 22

[Stuart Parmenter]

dup

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

Comment 23

[Diego Biurrun]

Considering that the crash happens at the same URL, this should be safe to verify.