From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17 i586; en-US; m18) Gecko/20000914 BuildID: 2000091408 When loading http://www.strato.de/, mozilla only starts displaying one of the advertising popups and before rendering that or the main page, generates a segfault. Reproducible: Always Steps to Reproduce: 1.type in adress field: http://www.strato.de/ 2.Press return :-) 3.Wait for crash Actual Results: JavaScript error: line 3: uncaught exception: [Exception... "Component does not have requested i JavaScript error: line 3: uncaught exception: [Exception... "Component does not have requested i JavaScript error: line 0: uncaught exception: [Exception... "Component does not have requested i JavaScript error: line 0: uncaught exception: [Exception... "Component does not have requested i ./run-mozilla.sh: line 29: 1585 Speicherzugriffsfehler $prog ${1+"$@"} Expected Results: render the page or maybe display an error I'm using glibc 2.1.3 (SuSE 7.0 with the glibc thread mutex fix applied), modern skin.

does not crash me with today's linux build 091408 on redhat 6.2 with glibc 2.1.3-15

I see the crash with 2000-09-14-08 on Linux (RH 6.2, glibc 2.1.3-15).

Making testcase

Marking confirmed. Note: I checked with M17 and both the testcase and http://www.strato.de load fine.

Interesting, I'm not crashing on the actual site but I am crashing with the testcase. 091508 linux mozilla build.

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

Win 98 M17 Build ID:2000080712 I did not experience a crash for this bug either on the given site or the testcase. I did get a blank screen for the test case but no abnormal behavior.

Cameron: your build is quite old. Looks like M17 does not crash on the URL and testcase.

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

adding qawanted as we need more linux testing

I can crash linux 2000091806 when doing a reload of www.strato.de (see also bug 53148, which also involves mac as well as linux.) nsHTTPFinalListener::OnDataAvailable() nsHTTPCacheListener::OnDataAvailable() nsDiskCacheRecordChannel::OnDataAvailable() nsOnDataAvailableEvent::HandleEvent() nsStreamListenerEvent::HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xe52a (0x4089052a) libglib-1.2.so.0 + 0xfbe6 (0x40891be6) libglib-1.2.so.0 + 0x101a1 (0x408921a1) libglib-1.2.so.0 + 0x10341 (0x40892341) libgtk-1.2.so.0 + 0x8c209 (0x407b9209) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x181eb (0x402531eb) I also crash on the testcase, but the stack in somewhat different. nsHTTPResponse::GetContentLength() nsHTTPServerListener::OnDataAvailable() nsOnDataAvailableEvent::HandleEvent() nsStreamListenerEvent::HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xe52a (0x4089052a) libglib-1.2.so.0 + 0xfbe6 (0x40891be6) libglib-1.2.so.0 + 0x101a1 (0x408921a1) libglib-1.2.so.0 + 0x10341 (0x40892341) libgtk-1.2.so.0 + 0x8c209 (0x407b9209) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x181eb (0x402531eb) -> necko

I see the crash with linux build 2000092010, both with www.strato.de and the testcase...

*spam* adding crash keyword...

getting this in the rtm+ radar.

Something interesting. If one starts off with no profile, so that mozilla creates a clean one, www.strato.de loads fine. If one then restarts the browser and tries to access the site again, the crash occurs.

The stack dump I just appended to this bug report pinpoints the source of the crash. Notice frame 40 and frame 2. We're getting OnStopRequest() called inside OnDataAvailable(). nsDiskCacheRecordChannel releases its listener, which in turn frees a bunch of memory (memory referenced in frames 40, 39, and 38). So, by the time the program gets back to the OnDataAvailable handler of nsHTTPFinalListener, we get seg faults, with the stack dumps we've been seeing so far. A possible fix would be to add refs to objects, that would be released in OnStopRequest(), on entry to OnDataAvailable() and then release the objects on exit from OnDataAvailable().

great investigation darin. am cc'ing dp and neeti to see if they see something related to their cache changes here.

PDT marking [rtm need info] until patch and code reviews are available.

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

verif dup