5/3 builds on Linux/Win95/Mac are crashing at www.zdnet.com Happens on viewer also, at least on Linux (no viewer in commercial builds for mac/win) The link to the windows talkback report is http://cyclone/reports/incidenttemplate.CFM?reportID=1076&style=0&tc=1&cp=1&ck1= SNub+trigger+event+time&cd1=1999%2F05%2F03&bbid=8045911

Chris -- it's crashing in table frame code. Please look: nsFrame::DeleteFrame(nsFrame * const 0x03613ae0, nsIPresContext & {...}) line 376 + 17 bytes nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x036129a0, nsIPresContext & {...}) line 82 nsTableFrame::DeleteFrame(nsTableFrame * const 0x036129a0, nsIPresContext & {...}) line 350 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x03612aa0, nsIPresContext & {...}) line 82 nsLineBox::DeleteLineList(nsIPresContext & {...}, nsLineBox * 0x0361a7c0) line 158 nsBlockFrame::DeleteFrame(nsBlockFrame * const 0x03611640, nsIPresContext & {...}) line 803 + 16 bytes nsAreaFrame::DeleteFrame(nsAreaFrame * const 0x03611640, nsIPresContext & {...}) line 102 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x036116d0, nsIPresContext & {...}) line 82 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x03611b40, nsIPresContext & {...}) line 82 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x03611bd0, nsIPresContext & {...}) line 82 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x03611ea0, nsIPresContext & {...}) line 82 nsTableFrame::DeleteFrame(nsTableFrame * const 0x03611ea0, nsIPresContext & {...}) line 350 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x03611fa0, nsIPresContext & {...}) line 82 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsBlockFrame::DeleteFrame(nsBlockFrame * const 0x035e5940, nsIPresContext & {...}) line 808 nsLineBox::DeleteLineList(nsIPresContext & {...}, nsLineBox * 0x035e5880) line 158 nsBlockFrame::DeleteFrame(nsBlockFrame * const 0x035e5ef0, nsIPresContext & {...}) line 803 + 16 bytes nsAreaFrame::DeleteFrame(nsAreaFrame * const 0x035e5ef0, nsIPresContext & {...}) line 102 nsFrameList::DeleteFrame(nsIPresContext & {...}, nsIFrame * 0x035e5ef0) line 115 RootFrame::Reflow(RootFrame * const 0x035e4374, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 187 nsContainerFrame::ReflowChild(nsIFrame * 0x035e4370, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 389 + 28 bytes nsScrollFrame::Reflow(nsScrollFrame * const 0x035e4d34, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 394 nsContainerFrame::ReflowChild(nsIFrame * 0x035e4d30, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 389 + 28 bytes ViewportFrame::Reflow(ViewportFrame * const 0x035e3174, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 434 nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x03b5c080, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsSize & {...}, nsIRenderingContext & {...}) line 169 PresShell::ProcessReflowCommands(PresShell * const 0x035c33e0) line 1225 PresShell::ExitReflowLock(PresShell * const 0x035c33e0) line 658 PresShell::ReconstructFrames() line 1692 PresShell::StyleSheetAdded(PresShell * const 0x035c33e8, nsIDocument * 0x01070050, nsIStyleSheet * 0x03b4ef80) line 1700 nsHTMLDocument::InsertStyleSheetAt(nsHTMLDocument * const 0x01070104, nsIStyleSheet * 0x03b4ef80, int 1, int 1) line 523 HTMLContentSink::LoadStyleSheet(nsIURL * 0x03aeb340, nsIUnicharInputStream * 0x03b4f6a0, int 0, const nsString & {"ZDNet Styles"}, const nsString & {""}, nsIHTMLContent * 0x03aeb43c, int 1) line 3131 nsDoneLoadingStyle(nsIUnicharStreamLoader * 0x03aeb090, nsString & {"<STYLE TYPE="text/css"> <!-- A:hover { color:#FF0000; } input { font-family: Ar"}, void * 0x03aeb0e0, unsigned int 0) line 2188 + 54 bytes nsUnicharStreamLoader::OnStopBinding(nsUnicharStreamLoader * const 0x03aeb094, nsIURL * 0x03aeb340, unsigned int 0, const unsigned short * 0x03af4540) line 156 + 31 bytes nsDocumentBindInfo::OnStopBinding(nsDocumentBindInfo * const 0x03aecfc0, nsIURL * 0x03aeb340, unsigned int 0, const unsigned short * 0x03af4540) line 2095 + 30 bytes OnStopBindingProxyEvent::HandleEvent(OnStopBindingProxyEvent * const 0x03af5180) line 591 + 45 bytes StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x03af5184) line 471 + 12 bytes PL_HandleEvent(PLEvent * 0x03af5184) line 476 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x0100e190) line 437 + 9 bytes _md_EventReceiverProc(HWND__ * 0x2e6c040a, unsigned int 49429, unsigned int 0, long 16834960) line 799 + 9 bytes USER32! 77e71250() 0100e190()

Here is a minimal test case. nsFrame::DeleteFrame()is being called on the nsButtonControlFrame (submit button) which has already been deleted somehow (no destructor was called) and crashing when it uses its mView. ---- test0.html ---- <HTML> <HEAD> <LINK REL="STYLESHEET" TYPE="text/css" HREF=foo.css"> </HEAD> <BODY> <ILAYER NAME="AD" LEFT="0" TOP="0" WIDTH="590"> <TABLE ALIGN="LEFT"> <TR> <TD> <TABLE> <FORM> <TR> <TD> <INPUT TYPE="SUBMIT"></TD></FORM></TR></TABLE></TD></TR></TABLE> <ILAYER> </BODY> </HTML> --- foo.css ----- <STYLE TYPE="text/css"> A:hover {color:#FF0000; }

In the small test case, the submit button's nsFormControlFrame::Reflow() creates its view but some other frame deletes that view before the submit button's nsFrame::DeleteFrame() accesses its mView. I discovered this by setting a breakpoint in nsFormControlFrame::Reflow (source line 284) recording the address of the view and then setting a breakpoint in nsView::~nsView(). Reassigning to Vidur as he agreed to take a look.

Is this perhaps related to bug #5213?

As Chris mentioned, the crash has to do with a view being prematurely deleted. In this case, the ILAYER's frame is in the line list for the body and gets deleted before the frames corresponding to the contents of the ILAYER (in the floaters list). This breaks the assumption that frame children are deleted before the frame. Since there's an INPUT control in the ILAYER (really any frame that has a view associated with it), its view is a child of the ILAYER's view. When the ILAYER's frame is deleted, it deletes the corresponding view and the view's children. Since the INPUT control's frame is in the floaters list, it hasn't yet been deleted and had a chance to relinquish its view. This is really a Troy bug. I'll hold onto it for now but it'll have to wait for M7 or M8.

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

With the July 01 build (Mac , Win 98, and Linux), the page loads without crashing.

I am marking fixed as the test case also does not crash on any platform using 7/1 build.