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

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P4)

Description

[Martijn Wargers (dead)]

Attachment: binding needed for testcase

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]

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

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...

Comment 3

[Daniel Veditz [:dveditz]]

Is this a potentially critical crash? null deref?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Looks like a virtual function call on a null pointer; I suspect that that's pretty consistent on this testcase.

Comment 5

[Martijn Wargers (dead)]

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?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Works for me too, on Mac. Marking so.

Comment 7

[Bob Clary [:bc] (inactive)]

crash test landed
http://hg.mozilla.org/mozilla-central/rev/e37c7a3a82df