Closed Bug 93658 Opened 23 years ago Closed 23 years ago

Page crashes mozilla, but only over the network

Categories

(Core :: Graphics: ImageLib, defect)

x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED DUPLICATE of bug 89595
Future

People

(Reporter: kbh7, Assigned: pavlov)

References

()

Details

(Whiteboard: [needs review/superreview])

Attachments

(1 file, 1 obsolete file)

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:  (...)
Confirmed on linux 0.9.3 with talkback build
Talkback ID: TB33789072X
Incident ID 33789072
Stack Signature libc.so.6 + 0x2ce54 (0x404e1e54) ec83acd8
Bug ID
Trigger Time 2001-08-06 07:34:22
Email Address con@kolivas.mine.nu
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() 
does it crash mozilla if image loading is off ;-?
Assignee: asa → pavlov
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston
In this day of ultra-high-speed everything, I didn't know
that was still an option.  :-)

timeless@mac.com 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.)
Confirmed on linux 0.9.3 as well as 2001081408, talkback ID TB34115004K

--> NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Still crashing with 0.9.5 and 2001110612 ---> REOPENED
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
TB37761710Q
TB37761704Y

No crash with images disabled
Still a problem with milestone 0.9.6.

TB38412545W

Stephen, could you be so kind and retrieve the talkback data? Thanks.
Stack Signature  libc.so.6 + 0x2d364 (0x404b3364) cab75d93
Bug ID
Trigger Time 2001-11-23 08:37:34
Email Address diego@biurrun.de
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) 
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+"$@"}
still a problem in 0.9.7 - TB784428Q
Target Milestone: --- → Future
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.
*** Bug 94183 has been marked as a duplicate of this bug. ***
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?
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.
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.
rpotts, darin, care to look at this?
i'd suggest using a nsresult for the status, like so:

  interface imgIDecoder {
    // ...
    readonly attribute nsresult status;
    // ...
  };
setting errorstate variable as true on encountering an error from the pnglib.
Making check for errorstate before processing data.
Keywords: review
Whiteboard: [needs review/superreview]
Depends on: 123569
Comment on attachment 68519 [details] [diff] [review]
patch file fixing the crash for a corrupted png

needs work
Attachment #68519 - Attachment is obsolete: true
No longer depends on: 123569
Blocks: 123569
dup

*** This bug has been marked as a duplicate of 89595 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → DUPLICATE
Considering that the crash happens at the same URL, this should be safe to verify.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: