Closed Bug 382745 Opened 13 years ago Closed 12 years ago

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

Categories

(Core :: Layout, defect, P4, critical)

x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: martijn.martijn, Unassigned)

Details

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

Crash Data

Attachments

(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.
Status: NEW → RESOLVED
Closed: 12 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
http://hg.mozilla.org/mozilla-central/rev/e37c7a3a82df
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.