From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (X11; I; Linux 2.2.12-20 i686) BuildID: 2000052120 Whenever you go to this page, the browser crashes. It looks like it's in the process of rendering the page, then the page top (navigation aids, and advertisments) start to look odd, then the whole shebang crashes. (other mozilla windows you have open crash too. The whole process ends) Reproducible: Always Steps to Reproduce: 1. Load url. 2. process dies. Actual Results: The entire process dies. All windows spawned in that session come down with it. Expected Results: Finish rendering the page. I seem to be able to re-produce this at will. If you need me to, I can mail out the full console output, however it doesn't SEEM to be anything pertinant... just a bunch of "WEBSHELL+ = #" where # ranges from 11-15, and a LOT of "Warning - table cell content max element height 285 greater than desired height 270" errors (or errors that differ in the numbers only). This is a redhat linux 6.1, slightly updated. celeron 300a, 128 megs If I can be of further help, please let me know at jprice@gatech.edu

Also confirmed with build 2000052120 on Win2K

Stack trace on PC/Linux, built from the 5/21 sources: #0 0x4172b330 in nsDSURIContentListener::DoContent () from libdocshell.so #1 0x406fc726 in nsDocumentOpenInfo::DispatchContent () from components/liburiloader.so #2 0x406fc173 in nsDocumentOpenInfo::OnStartRequest () from components/liburiloader.so #3 0x4069cd3a in nsHTTPFinalListener::OnStartRequest () from components/libnecko.so #4 0x4069ade1 in nsHTTPCacheListener::OnStartRequest () from components/libnecko.so #5 0x40684034 in nsDiskCacheRecordChannel::OnStartRequest () from components/libnecko.so #6 0x40658bb9 in nsOnStartRequestEvent::HandleEvent () from components/libnecko.so #7 0x406586b5 in nsStreamListenerEvent::HandlePLEvent () from components/libnecko.so #8 0x400bb35f in PL_HandleEvent () from libxpcom.so #9 0x400bb286 in PL_ProcessPendingEvents () from libxpcom.so #10 0x400bc139 in nsEventQueueImpl::ProcessPendingEvents () from libxpcom.so #11 0x40a272bf in event_processor_callback () from components/libwidget_gtk.so #12 0x40a2702f in our_gdk_io_invoke () from components/libwidget_gtk.so Adding crash kw, adding new info to summary.

This may be a duplicate of bug #39897, which seems to have the same URL and roughly the same stack backtrace (same routines called in the same order, from what I can see). I suspect that this makes it an all-platform bug, especially given bug #40261. I would like to nominate this bug as a dogfood /nsbeta2 issue, because I'm also seeing this crash on http://news.bbc.co.uk/ when one hits Back to come back out of a story to a main page. (I know this is a recent regression, too; it used to work a couple of weeks ago.) With crashes on at least two sites and if one prints on a third, and at least one of the sites being a fairly major news provider, it seems reasonably important to me. Mozilla.org may consider this non-dogfood and merely nsbeta2 on the grounds that the BBC et al is not /that/ important.

Putting on [nsbeta2+][dogfood-] radar. Does not need a fix ASAP for daily work, but we should fix this for beta2.

this is a dandy. At some point the docshell hands the URILoader it's nsIURIContentListener (via GetInterface(), not QI), and the URI loader pumps data to it and life is good. However, eventually that docshell is being destroyed (which breaks the ref from the content listener class, to the docshell, see http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#1348 ), but the content listener ref is still being maintained by the uri loader. Then, that ref is used, again, by the uri loader to DoContent(), but the listener object's (nsDSURIContentListener.cpp) mDocShell ptr is null and we try to access it. Simply making that ptr a comptr won't cut it because we'd be stuck w/ a circular reference. Something is broken in the design here. I think the uri loader is hanging onto a content listener too long (ie. after the docshell has gone away). Over to mscott.

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

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

I have verified that the two bugs Chris mentioned really have the same stack strace, and thus marked them dup of this one. Changing OS to All per bug 39897 (thanks to Chris for the hint), and adding some people from duped bugs to CC.

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

beta2+ = M16/m17.

This stack trace also occurs when trying to print the http://www.espn.go.com/ to a file (this URL is mentioned in bug 38768).

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

accepting.

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

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

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

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

Here's a first look at a potential fix for this crash. It definetly fixes the crash but is partially incomplete for two reasons: 1) When I load this page in 4.x, we get an etrade banner ad in the middle of the page (this was the url that was causing the crash). In seamonkey with my fix to prevent the crash, I never see the etrade banner ad. 2)The second problem is with the fact that I'm canceling and just falling out. I need to cancel the uriload and then go through the web progress to broadcast the fact that the url has been canceled. But I have another bug to track that =).

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

Adding top100 keyword (from bug 42564).

I've fixed the crash reported in this bug. However, for some reason layout isn't layout the part we are trying to reload when we used to crash in docshell. Marking fixed.

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

today's mozilla builds verified: Linux 2000062608 NT 2000062609

I'm seeing this bug again in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 http://www.washingtonpost.com/wp-dyn/articles/A61543-2004Mar15.html If the link doesnt work, just try any Washington Post article from http://news.google.com Thanks!

Matthew, please report this as a new bug. I don't want to repoen this bug.