455063 - ###!!! ASSERTION: no initial containing block: 'mInitialContainingBlock

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Boris Zbarsky [:bzbarsky]]

We hit this assertion on the testcase in the URL field, with this stack:

#0  nsCSSFrameConstructor::GetFloatContainingBlock (this=0x7f82c20, aFrame=0xe8150f4) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:7719
#1  0x02e1c27e in nsCSSFrameConstructor::ConstructInline (this=0x7f82c20, aState=@0xbfffc678, aDisplay=0xe8128cc, aContent=0x7f92d20, aParentFrame=0xe8128f0, aStyleContext=0x17dcf80, aIsPositioned=0, aNewFrame=0xe812974) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:12430
#2  0x02e1a4a8 in nsCSSFrameConstructor::ConstructFrameByDisplayType (this=0x7f82c20, aState=@0xbfffc678, aDisplay=0xe8128cc, aContent=0x7f92d20, aNameSpaceID=3, aTag=0x1008cf4, aParentFrame=0xe8128f0, aStyleContext=0x17dcf80, aFrameItems=@0xbfffc4f0, aHasPseudoParent=0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:6548
#3  0x02e1b0ca in nsCSSFrameConstructor::ConstructFrameInternal (this=0x7f82c20, aState=@0xbfffc678, aContent=0x7f92d20, aParentFrame=0xe8128f0, aTag=0x1008cf4, aNameSpaceID=3, aStyleContext=0x17dcf80, aFrameItems=@0xbfffc4f0, aXBLBaseTag=0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:7515
#4  0x02e1b547 in nsCSSFrameConstructor::ConstructFrame (this=0x7f82c20, aState=@0xbfffc678, aContent=0x7f92d20, aParentFrame=0xe8128f0, aFrameItems=@0xbfffc4f0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:7336
#5  0x02e1c66d in nsCSSFrameConstructor::ProcessChildren (this=0x7f82c20, aState=@0xbfffc678, aContent=0x7f928c0, aFrame=0xe8128f0, aCanHaveGeneratedContent=1, aFrameItems=@0xbfffc4f0, aParentIsBlock=1) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:11200
#6  0x02e1ce68 in nsCSSFrameConstructor::ConstructBlock (this=0x7f82c20, aState=@0xbfffc678, aDisplay=0xe812808, aContent=0x7f928c0, aParentFrame=0x17dc98c, aContentParentFrame=0x17dc98c, aStyleContext=0x17dce80, aNewFrame=0xbfffc5e4, aFrameItems=@0xbfffc5bc, aAbsPosContainer=0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:12293
#7  0x02e24ad9 in nsCSSFrameConstructor::ConstructDocElementFrame (this=0x7f82c20, aState=@0xbfffc678, aDocElement=0x7f928c0, aParentFrame=0x17dc98c, aNewFrame=0xbfffc758) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:4240
#8  0x02e24ff9 in nsCSSFrameConstructor::ReconstructDocElementHierarchyInternal (this=0x7f82c20) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:7623
#9  0x02e250b5 in nsCSSFrameConstructor::ReconstructDocElementHierarchy (this=0x7f82c20) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:7532
#10 0x02e25355 in nsCSSFrameConstructor::RecreateFramesForContent (this=0x7f82c20, aContent=0x7f928c0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:11048
#11 0x02e256b5 in nsCSSFrameConstructor::ProcessRestyledFrames (this=0x7f82c20, aChangeList=@0xbfffc8e0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:9781
#12 0x02e8b2e5 in PresShell::RecreateFramesFor (this=0x12e5600, aContent=0x7f928c0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsPresShell.cpp:3415

We might not need all the XBL goop, but I'm not sure yet.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Minimalish testcase

We probably just need to reset the member somewhere.

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 3

[Mats Palmgren (inactive)]

Attachment: crashtest.diff

Comment 4

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

ConstructDocElementFrame() initializes 'mInitialContainingBlock' too
late for the cases where 'processChildren' is false, i.e. in the 
ConstructTableFrame() and ConstructBlock() cases because these two
process there own children.
http://hg.mozilla.org/mozilla-central/annotate/4dfc88a342b2/layout/base/nsCSSFrameConstructor.cpp#l4168

The changed comment referred to a 'mInitialContainingBlock' at the end of
the method which wasn't there - I assume it's the processing at the end in
general (the 'mDocElementContainingBlock' bit).

Comment 5

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

+  if (!mInitialContainingBlock) {
+    // The frame we're constructing will be the initial containing block.
+    // Set mInitialContainingBlock before processing children.
+    mInitialContainingBlock = blockFrame;
+  }

When the root element has columns, I think this is setting mInitialContainingBlock to the inner block, not the columnset frame. I think we need to use *aNewFrame here.

Comment 6

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

Also, in ConstructDocElementHierarchy, when we get around to setting mInitialContainingBlock, we should probably assert that if it's not null then it's already the value we're going to set it to.

Comment 7

[Mats Palmgren (inactive)]

Attachment: Patch rev. 2

Good points.  I did the assertion more restrictive than you suggested,
requiring it must be set to 'contentFrame' unless 'processChildren'
is true where it must be set to null.

I've added a third crashtest that covers the column case (it triggers
the new assertion using my first patch).

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

Is this going to land soon?  It would be very nice for those of us hacking on Thunderbird, as it seems to fix an assertion that's hit very very frequently, and makes it painful to run under the debugger with XPCOM_DEBUG_BREAK set to "trap".

Comment 9

[Serge Gautherie (:sgautherie)]

(SeaMonkey has this too.)

Comment 10

[Boris Zbarsky [:bzbarsky]]

Pushed changeset ad4d8bd0f99b to fix this.

Comment 11

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081009 SeaMonkey/2.0a2pre] (home, debug default) (W2Ksp4)

I had no explicit steps, but I don't seem to get the assertion anymore :-)

V.Fixed