start up browser, go to http://bugzilla.mozilla.org/buglist.cgi? bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=sspitzer&emailtype 1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bu gidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalu e=&target_milestone=mozilla0.9.1&short_desc=&short_desc_type=substring&long_desc =&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whit eboard=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&field0 -0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=% 22Importance%22 after it loads, change 0.9.1 to 0.9.2 in the url bar. crash. here's the stack trace: this was from a trunk build from about 4 or 5 pm, may 31 nsCOMPtr<nsIStyleRule>::nsCOMPtr<nsIStyleRule>(nsIStyleRule * 0x044c4a50) line 533 + 13 bytes nsRuleNode::WalkRuleTree(const nsStyleStructID & eStyleStruct_Outline, nsIStyleContext * 0x02989e20, nsRuleData * 0x0012edac, nsCSSStruct * 0x0012ee14) line 821 nsRuleNode::GetOutlineData(nsIStyleContext * 0x02989e20) line 723 + 43 bytes nsRuleNode::GetStyleData(nsStyleStructID eStyleStruct_Outline, nsIStyleContext * 0x02989e20) line 4462 + 12 bytes nsStyleContext::GetStyleData(nsStyleStructID eStyleStruct_Outline) line 394 nsBlockFrame::Paint(nsBlockFrame * const 0x0292f77c, nsIPresContext * 0x03f6b0e0, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 5036 + 19 bytes nsContainerFrame::PaintChild(nsIPresContext * 0x03f6b0e0, nsIRenderingContext & {...}, const nsRect & {...}, nsIFrame * 0x0292f77c, nsFramePaintLayer eFramePaintLayer_Underlay) line 229 nsBlockFrame::PaintChildren(nsIPresContext * 0x03f6b0e0, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 5196 nsBlockFrame::Paint(nsBlockFrame * const 0x02a1b958, nsIPresContext * 0x03f6b0e0, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 5074 nsContainerFrame::PaintChild(nsIPresContext * 0x03f6b0e0, nsIRenderingContext & {...}, const nsRect & {...}, nsIFrame * 0x02a1b958, nsFramePaintLayer eFramePaintLayer_Underlay) line 229 nsContainerFrame::PaintChildren(nsIPresContext * 0x03f6b0e0, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 173 nsHTMLContainerFrame::Paint(nsHTMLContainerFrame * const 0x02a1b0cc, nsIPresContext * 0x03f6b0e0, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 122 CanvasFrame::Paint(CanvasFrame * const 0x02a1b0cc, nsIPresContext * 0x03f6b0e0, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 409 + 25 bytes PresShell::Paint(PresShell * const 0x03f45824, nsIView * 0x044c3390, nsIRenderingContext & {...}, const nsRect & {...}) line 5243 + 34 bytes nsView::Paint(nsView * const 0x044c3390, nsIRenderingContext & {...}, const nsRect & {...}, unsigned int 128, int & 268601973) line 275 nsViewManager::RenderDisplayListElement(DisplayListElement2 * 0x044d7140, nsIRenderingContext & {...}) line 1438 nsViewManager::RenderViews(nsIView * 0x044c79a0, nsIRenderingContext & {...}, const nsRect & {...}, int & 0) line 1363 nsViewManager::Refresh(nsIView * 0x044c79a0, nsIRenderingContext * 0x044d73d0, const nsRect * 0x0012f5d8, unsigned int 1) line 900 nsViewManager::DispatchEvent(nsViewManager * const 0x03ef8040, nsGUIEvent * 0x0012f718, nsEventStatus * 0x0012f61c) line 1957 HandleEvent(nsGUIEvent * 0x0012f718) line 68 nsWindow::DispatchEvent(nsWindow * const 0x044c7ad4, nsGUIEvent * 0x0012f718, nsEventStatus & nsEventStatus_eIgnore) line 712 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f718, nsEventStatus & nsEventStatus_eIgnore) line 738 nsWindow::OnPaint() line 4003 + 28 bytes nsWindow::ProcessMessage(unsigned int 15, unsigned int 0, long 0, long * 0x0012fb4c) line 2998 + 17 bytes nsWindow::WindowProc(HWND__ * 0x006500b4, unsigned int 15, unsigned int 0, long 0) line 979 + 27 bytes USER32! 77e13eb0() USER32! 77e1591b() USER32! 77e1595d() NTDLL! 77f9fb83() USER32! 77e192da() nsAppShellService::Run(nsAppShellService * const 0x010b28b0) line 418 main1(int 2, char * * 0x00484190, nsISupports * 0x00000000) line 1128 + 32 bytes main(int 2, char * * 0x00484190) line 1426 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87903()

Moz Win32 build 2001053120 (as shown on the title bar) is very crashy... (I download it from http://ftp.mozilla.org/pub/mozilla/nightly/2001-05-31-22-trunk/ actually)

->hyatt Seeing on Linux too. Marking topcrash because it's going to be on the lists in a few days.

(gdb) frame 5 #5 0x4168a8ac in nsRuleNode::WalkRuleTree(nsStyleStructID const&, nsIStyleContext*, nsRuleData*, nsCSSStruct*) (this=0x856f7a4, aSID=@0xbfffe1fc, aContext=0x856f7dc, aRuleData=0xbfffe208, aSpecificData=0xbfffe258) at /builds/seamonkey/mozilla/content/html/style/src/nsRuleNode.cpp:820 820 nsCOMPtr<nsIStyleRule> rule = mRule; Current language: auto; currently c++ (gdb) p mRule $1 = (class nsIStyleRule *) 0x8570730 (gdb) p *mRule $2 = {<nsISupports> = {_vptr.nsISupports = 0x776f7262}, <No data fields>} (gdb) x/wa *(void**)mRule 0x776f7262: Cannot access memory at address 0x776f7262 So it looks like the memory pointed to by mRule is trashed (maybe freed and reallocated?).

MTBF has dropped for me from about 12 hours to about 10 minutes. I've seen this same crash 5 times this morning and I haven't even finished the smoketests. I think we should hold the tree for this. I can't reproduce this with any one of the individual smoketests so technically it's not a smoketest but I'm co-opting the keyword and severity to flag this as a tree closer.

Seems like the rules are dying before the frames do. I would have expected that to be impossible, since I would have thought that the styleset would have strongly held stylesheets which strongly hold rules. A fix to try here would be to make nsRuleNodes have strong refs to their corresponding rules. That would be a shame though, since turning a ptr into a COMPtr will bloat the rule nodes by 4 more bytes.

An nsCOMPtr should be the same size as a raw pointer.

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

hyatt, I don't understand your comment about the frames dying before the rules. In my stack, we are in a Paint stack, so the frames are not being destroyed AFAICT. Could it be that the rules are simply moving? And, why only on some pages? Here is my stack in Win2K: 33494023() nsCOMPtr<nsIStyleRule>::nsCOMPtr<nsIStyleRule>(nsIStyleRule * 0x0494c4d0) line 535 nsRuleNode::WalkRuleTree(const nsStyleStructID & eStyleStruct_Outline, nsIStyleContext * 0x02df28ec, nsRuleData * 0x0012edac, nsCSSStruct * 0x0012ee14) line 821 nsRuleNode::GetOutlineData(nsIStyleContext * 0x02df28ec) line 723 + 43 bytes nsRuleNode::GetStyleData(nsStyleStructID eStyleStruct_Outline, nsIStyleContext * 0x02df28ec) line 4462 + 12 bytes nsStyleContext::GetStyleData(nsStyleStructID eStyleStruct_Outline) line 394 nsBlockFrame::Paint(nsBlockFrame * const 0x02df2760, nsIPresContext * 0x0467a450, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 5036 + 19 bytes nsContainerFrame::PaintChild(nsIPresContext * 0x0467a450, nsIRenderingContext & {...}, const nsRect & {...}, nsIFrame * 0x02df2760, nsFramePaintLayer eFramePaintLayer_Underlay) line 229 nsBlockFrame::PaintChildren(nsIPresContext * 0x0467a450, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 5196 nsBlockFrame::Paint(nsBlockFrame * const 0x02d74278, nsIPresContext * 0x0467a450, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 5074 nsContainerFrame::PaintChild(nsIPresContext * 0x0467a450, nsIRenderingContext & {...}, const nsRect & {...}, nsIFrame * 0x02d74278, nsFramePaintLayer eFramePaintLayer_Underlay) line 229 nsContainerFrame::PaintChildren(nsIPresContext * 0x0467a450, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 173 nsHTMLContainerFrame::Paint(nsHTMLContainerFrame * const 0x02d73874, nsIPresContext * 0x0467a450, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 122 CanvasFrame::Paint(CanvasFrame * const 0x02d73874, nsIPresContext * 0x0467a450, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay) line 409 + 25 bytes PresShell::Paint(PresShell * const 0x0465d324, nsIView * 0x0494c980, nsIRenderingContext & {...}, const nsRect & {...}) line 5243 + 34 bytes nsView::Paint(nsView * const 0x0494c980, nsIRenderingContext & {...}, const nsRect & {...}, unsigned int 128, int & 268601973) line 275 nsViewManager::RenderDisplayListElement(DisplayListElement2 * 0x04968c50, nsIRenderingContext & {...}) line 1438 nsViewManager::RenderViews(nsIView * 0x0494cd70, nsIRenderingContext & {...}, const nsRect & {...}, int & 0) line 1363 nsViewManager::Refresh(nsIView * 0x0494cd70, nsIRenderingContext * 0x04968ee0, const nsRect * 0x0012f5d8, unsigned int 1) line 900 nsViewManager::DispatchEvent(nsViewManager * const 0x046126e0, nsGUIEvent * 0x0012f718, nsEventStatus * 0x0012f61c) line 1957 HandleEvent(nsGUIEvent * 0x0012f718) line 68 nsWindow::DispatchEvent(nsWindow * const 0x0494cc34, nsGUIEvent * 0x0012f718, nsEventStatus & nsEventStatus_eIgnore) line 712 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f718, nsEventStatus & nsEventStatus_eIgnore) line 738 nsWindow::OnPaint() line 4003 + 28 bytes nsWindow::ProcessMessage(unsigned int 15, unsigned int 0, long 0, long * 0x0012fb4c) line 2998 + 17 bytes nsWindow::WindowProc(HWND__ * 0x00070394, unsigned int 15, unsigned int 0, long 0) line 979 + 27 bytes USER32! 77e12e98() USER32! 77e139a3() USER32! 77e1395f() NTDLL! 77fa032f() USER32! 77e15824() nsAppShellService::Run(nsAppShellService * const 0x014a1220) line 418 main1(int 3, char * * 0x00484160, nsISupports * 0x00000000) line 1128 + 32 bytes main(int 3, char * * 0x00484160) line 1426 + 37 bytes mainCRTStartup() line 338 + 17 bytes

Hyatt, I see a crash at every skin change. From your comments I assume this is the same one. If this bug is that general, shouldn't we change it's summary?

This is caused by a bad interaction of paint suppression and the new style code. I just bit the bullet and made the rule nodes strongly own the rules and this fixes the problem. r and sr please.

Remove the stale second sentence in the comment? - nsIStyleRule* mRule; // A pointer to our specific rule. This can be weak, since the sheet owns it. + nsCOMPtr<nsIStyleRule> mRule; // A pointer to our specific rule. This can be weak, since the sheet owns it. /be

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

Is this another problem caused by the document viewer being |Destroy|ed but the frames not being destroyed? (bug 80203) If not, what was triggering the destruction of the rules? Other than brendan's comment, patch seems fine, at least until the above issue is figured out, so r=dbaron. (Do run a leak test, though. What owns the rule nodes? Will everything still go away?) But beware that a little bit of your <font size=7> patch (bug 83658) slipped into this one, and it won't compile unless you check in the other half of that patch with it or remove that bit.

In the old trunk, style contexts strongly owned all the rules they matched, so this creates a more or less equivalent situation.

brendan, can I take your comment to be an sr? I removed the stale comment.

Someone told me that nsCOMPtrs were now bigger than raw pointers. Was that a myth?

Fixed.

It's a myth. sizeof(nsISupports*) == 4 sizeof(nsCOMPtr<nsISupports>) == 4 sizeof(nsCOMPtr<nsISimpleEnumerator>) == 4

Yay!

I very carefully did not stamp sr=brendan@mozilla.org, but oh well. I'm lurking and working on something else, not paying enough attention except to stale weak ref comments! But it looked ok to me. /be

just built linuc cvs. Place i saw this crash repeatedly (tinderbox page, link to remaining 0.9.1 bugs) now load fine. On the fly reloads too, back, forth, back, click link.. can't make it crash anymore.

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

Adding [@ nsRuleNode::WalkRuleTree] and [@ nsRuleNode::GetUIResetData] to summary for tracking purposes, since those appeared to be the most common functions for this crash under all the 0x???????? stack signatures.

According to the latest Talkback data, this crash last occurred with build 2001060109...so verifying this fixed.