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

VERIFIED FIXED in mozilla1.9.1b2



10 years ago
10 years ago


(Reporter: bz, Assigned: mats)


({assertion, regression, testcase})

assertion, regression, testcase
Dependency tree / graph
Bug Flags:
wanted1.9.1 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)




(3 attachments, 2 obsolete attachments)

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.
Flags: blocking1.9.1?
Created attachment 338363 [details]
Minimalish testcase

We probably just need to reset the member somewhere.


10 years ago
Assignee: roc → mats.palmgren
Keywords: assertion, regression, testcase
OS: Mac OS X → All
Hardware: PC → All

Comment 2

10 years ago
Created attachment 338410 [details]
Testcase #2

Comment 3

10 years ago
Created attachment 338411 [details] [diff] [review]

Comment 4

10 years ago
Created attachment 338414 [details] [diff] [review]
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.

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).
Attachment #338414 - Flags: superreview?(roc)
Attachment #338414 - Flags: review?(roc)
+  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.
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

10 years ago
Created attachment 338990 [details] [diff] [review]
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).
Attachment #338411 - Attachment is obsolete: true
Attachment #338414 - Attachment is obsolete: true
Attachment #338990 - Flags: superreview?(roc)
Attachment #338990 - Flags: review?(roc)
Attachment #338414 - Flags: superreview?(roc)
Attachment #338414 - Flags: review?(roc)
Attachment #338990 - Flags: superreview?(roc)
Attachment #338990 - Flags: superreview+
Attachment #338990 - Flags: review?(roc)
Attachment #338990 - Flags: review+
Blocks: 457213

Comment 8

10 years ago
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".
(SeaMonkey has this too.)
Flags: blocking1.9.1? → wanted1.9.1+
Pushed changeset ad4d8bd0f99b to fix this.
Last Resolved: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
[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 :-)

Target Milestone: --- → mozilla1.9.1b2
You need to log in before you can comment on or make changes to this bug.