Closed Bug 382745 Opened 15 years ago Closed 14 years ago

Crash [@ nsHTMLReflowState::GetNearestContainingBlock] using generated content in binding, tree stuff and position: fixed


(Core :: Layout, defect, P4)

Windows XP





(Reporter: martijn.martijn, Unassigned)


(Keywords: crash, testcase, Whiteboard: [sg:nse?] null-deref [dbaron-1.9:Rs] wfm on trunk)

Crash Data


(2 files)

See upcoming testcase, which crashes Mozilla on load.
It also crashes on branch, so I'm marking it security sensitive for now.

Talkback ID: TB32720948H
nsHTMLReflowState::GetNearestContainingBlock  [mozilla/layout/generic/nshtmlreflowstate.cpp, line 653]
nsHTMLReflowState::InitAbsoluteConstraints  [mozilla/layout/generic/nshtmlreflowstate.cpp, line 1062]
nsHTMLReflowState::InitConstraints  [mozilla/layout/generic/nshtmlreflowstate.cpp, line 1757]
nsHTMLReflowState::Init  [mozilla/layout/generic/nshtmlreflowstate.cpp, line 288]
nsHTMLReflowState::nsHTMLReflowState  [mozilla/layout/generic/nshtmlreflowstate.cpp, line 181]
nsAbsoluteContainingBlock::ReflowAbsoluteFrame  [mozilla/layout/generic/nsabsolutecontainingblock.cpp, line 389]
Attached file testcase
There are some nice asserts here about shallow unbinds.  Those are probably the first thing to look into....  I see them happening on an hbox under nsXBLBinding::GenerateAnonymousContent with the following callstack:

#0  0xb4f470aa in nsGenericElement::UnbindFromTree (this=0x8c50e70, aDeep=0, 
    aNullParent=1) at ../../../../mozilla/content/base/src/nsGenericElement.cpp:2034
#1  0xb526dc63 in nsXULElement::UnbindFromTree (this=0x8c50e70, aDeep=0, aNullParent=1)
    at ../../../../../mozilla/content/xul/content/src/nsXULElement.cpp:822
#2  0xb4ecf96a in nsAttrAndChildArray::Clear (this=0x8b44290)
    at ../../../../mozilla/content/base/src/nsAttrAndChildArray.cpp:650
#3  0xb4ece1c4 in nsAttrAndChildArray::~nsAttrAndChildArray ()
    at ../../../../dist/include/xpcom/nsAutoPtr.h:961
#4  0xb4f43afd in ~nsGenericElement (this=0x8b44278)
    at ../../../../mozilla/content/base/src/nsGenericElement.cpp:1068
#5  0xb5079cbc in nsXMLElement::~nsXMLElement$delete ()
    at ../../dist/include/xpcom/nsTArray.h:698
#6  0xb4f6014c in nsNodeUtils::LastRelease (aNode=0x8b44278)
    at ../../../../mozilla/content/base/src/nsNodeUtils.cpp:227
#7  0xb4f4b680 in nsGenericElement::Release (this=0x8b44278)
    at ../../../../mozilla/content/base/src/nsGenericElement.cpp:3343
#8  0xb5078e4c in nsXMLElement::Release (this=0x8b44278)
    at ../../../../../mozilla/content/xml/content/src/nsXMLElement.cpp:100
#9  0xb4c71d00 in ~nsCOMPtr (this=0xbfffdb60)
    at ../../../dist/include/xpcom/nsCOMPtr.h:583
#10 0xb510552b in nsXBLBinding::GenerateAnonymousContent (this=0x8b442b0)
    at ../../../../mozilla/content/xbl/src/nsXBLBinding.cpp:620

The node with a non-null GetCurrentDoc() is a XULElement.  And yes, this is a pretty recent tree that should have the changes to make XUL not lie about the current doc when cloned...
Flags: blocking1.9?
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
Is this a potentially critical crash? null deref?
Looks like a virtual function call on a null pointer; I suspect that that's pretty consistent on this testcase.
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
Flags: blocking1.9? → blocking1.9+
Whiteboard: [dbaron-1.9:Rw]
Whiteboard: [dbaron-1.9:Rw] → [dbaron-1.9:Rs]
This is now worksforme, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110103 Minefield/3.0a9pre
Can this bug be marked worksforme?
Works for me too, on Mac. Marking so.
Closed: 14 years ago
Priority: -- → P4
Resolution: --- → WORKSFORME
Flags: in-testsuite?
Whiteboard: [dbaron-1.9:Rs] → [sg:nse?] null-deref [dbaron-1.9:Rs] wfm on trunk
Group: core-security
crash test landed
Flags: in-testsuite? → in-testsuite+
Crash Signature: [@ nsHTMLReflowState::GetNearestContainingBlock]
You need to log in before you can comment on or make changes to this bug.