Just launch and go to 800.com. It crashes before the page finishes loading. (Apologies for the "random website happens to sling barbs at Mozilla today" bug. I hate getting those.) It's been happening for me in both today's trunk Mozilla build and today's Netscape PR3 build. The last thing gasped out by the console window is: WEBSHELL+ = 5 WEBSHELL+ = 6 ###!!! ASSERTION: reflow dirty lines failed. : '0', file nsBlockFrame.cpp, line 1748 ###!!! Break: at file nsBlockFrame.cpp, line 1748 ###!!! ASSERTION: reflow dirty lines failed. : '0', file nsBlockFrame.cpp, line 1748 ###!!! Break: at file nsBlockFrame.cpp, line 1748 ###!!! ASSERTION: reflow dirty lines failed. : '0', file nsBlockFrame.cpp, line 1748 ###!!! Break: at file nsBlockFrame.cpp, line 1748 Enabling Quirk StyleSheet Setting content window *** Pulling out the charset in SetSecurityButton Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (runnable)] I've been having a lot of trouble getting a stack trace from gdb 5.0-3 (which at least lets me debug Mozilla at all...) Multiple runs and some luck allowed me to build this composite: #0 SinkContext::SetPreAppend (this=0x0, aPreAppend=0) at nsHTMLContentSink.cpp:427 #1 0x4152a168 in HTMLContentSink::PostEvaluateScript (this=0x8735230, aBodyPresent=1) at nsHTMLContentSink.cpp:4569 #2 0x4152c5f2 in HTMLContentSink::ProcessSCRIPTTag (this=0x8735230, aNode=@0x8306c88) at nsHTMLContentSink.cpp:4961 #3 0x41524dd0 in HTMLContentSink::AddLeaf (this=0x8735230, aNode=@0x8306c88) at nsHTMLContentSink.cpp:3133 #4 0x40ac81a8 in CNavDTD::AddLeaf (this=0x870dcd0, aNode=0x8677028) at CNavDTD.cpp:3621 #5 0x40ac5849 in CNavDTD::HandleScriptToken (this=0x870dcd0, aNode=0x8677028) at CNavDTD.cpp:2073 #6 0x40ac7886 in CNavDTD::OpenContainer (this=0x870dcd0, aNode=0x8677028, aTag=eHTMLTag_script, aClosedByStartTag=1, aStyleStack=0x0) at CNavDTD.cpp:3290 #7 0x40ac35ed in CNavDTD::HandleDefaultStartToken (this=0x870dcd0, aToken=0x875a9c8, aChildTag=eHTMLTag_script, aNode=0x8677028) at CNavDTD.cpp:1141 #8 0x40ac4666 in CNavDTD::HandleStartToken (this=0x870dcd0, aToken=0x875a9c8) at CNavDTD.cpp:1569 #9 0x40ac289a in CNavDTD::HandleToken (this=0x870dcd0, aToken=0x0, aParser=0x872ade8) at CNavDTD.cpp:745 #10 0x40ac2064 in CNavDTD::BuildModel (this=0x870dcd0, aParser=0x872ade8, aTokenizer=0x8296688, anObserver=0x0, aSink=0x86dc640) at CNavDTD.cpp:485 #11 0x40ad8c0f in nsParser::BuildModel (this=0x872ade8) at nsParser.cpp:2010 #12 0x40ad89a5 in nsParser::ResumeParse (this=0x872ade8, allowIteration=1, aIsFinalChunk=0) at nsParser.cpp:1891 #13 0x40ad974f in nsParser::OnDataAvailable (this=0x872ade8, channel=0x8710f58, aContext=0x0, pIStream=0x87411bc, sourceOffset=0, aLength=1404) at nsParser.cpp:2343 #14 0x40bcbeb0 in nsDocumentOpenInfo::OnDataAvailable (this=0x870f7d0, aChannel=0x830a578, aCtxt=0x0, inStr=0x861068c, sourceOffset=0, count=1404) at nsURILoader.cpp:251 #15 0x409fcb23 in nsHTTPFinalListener::OnDataAvailable (this=0x8554708, aChannel=0x830a578, aContext=0x0, aStream=0x861068c, aSourceOffset=0, aCount=1404) at nsHTTPResponseListener.cpp:1190 #16 0x409c977d in InterceptStreamListener::OnDataAvailable (this=0x8610688, channel=0x830a578, ctxt=0x0, inStr=0x8679860, sourceOffset=0, count=1404) at nsCachedNetData.cpp:1207 #17 0x409fb1c1 in nsHTTPServerListener::OnDataAvailable (this=0x85f9450, channel=0x856bc2c, context=0x830a578, i_pStream=0x8679860, i_SourceOffset=3112, i_Length=1404) at nsHTTPResponseListener.cpp:554 #18 0x4099005f in nsOnDataAvailableEvent::HandleEvent (this=0x85c14b8) at nsAsyncStreamListener.cpp:400 #19 0x4098f2e7 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x85c14e0) at nsAsyncStreamListener.cpp:97 #20 0x4012821e in PL_HandleEvent (self=0x42103e38) at plevent.c:575 #21 0x4012803c in PL_ProcessPendingEvents (self=0x80ae8a8) at plevent.c:508 #22 0x40129e89 in nsEventQueueImpl::ProcessPendingEvents (this=0x80ae880) at nsEventQueue.cpp:356 If I can believe gdb, this appears to be a remarkable stack of deleted objects stumbling all over themselves: it seems like frame 15 was the last nondeleted object. In frames 14 through 1, all the "this" objects seem quite deleted. It's kind of neat that it lasted that long before finally crashing. So it seems that frame 15 in nsHTTPFinalListener::OnDataAvailable, line 1190 is referencing a deleted mListener object, so I'm dumping this on the necko team default recipient. Sorry.

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

verified dup