Crash [@ nsCSSFrameConstructor::ConstructXULFrame] with treecols, display:table

VERIFIED FIXED in mozilla1.9.1b3



11 years ago
6 years ago


(Reporter: jruderman, Assigned: roc)


(Blocks: 1 bug, {crash, testcase, verified1.9.1})

crash, testcase, verified1.9.1
Bug Flags:
blocking1.9.1 +
wanted1.9.0.x -
in-testsuite +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:critical], crash signature)


(2 attachments)



11 years ago
Created attachment 338060 [details]
testcase (crashes Firefox when loaded)
In nsCSSFrameConstructor::ConstructXULFrame we have aState.mPopupItems.containingBlock pointing to a deleted frame.
This is more fun.  We're hitting nsCSSFrameConstructor::ReconstructDocElementHierarchyInternal which caches things like mRootBox and its popup set frame. Then we blow away the frame tree (and in particular the nsPopupSetFrame that is the mPopupItems.containingBlock of this state).  Then we use this state to construct the new frame tree and die.  The other containing blocks we explicitly init to null, so those don't run into this problem.

Not sure whether this is a regression from roc's root frame changes.

In any case, we should either create a new state for constructing the new frametree or do a better job os sanitizing the old state.

Given comment 1, closing up for now.
Group: core-security
Flags: blocking1.9.1?
Can't reproduce using a Gran Paradiso nightly.
Flags: wanted1.9.0.x-

Comment 4

10 years ago
Indeed, today I found a related testcase that causes nsCSSFrameConstructor::ConstructFrameInternal to call 0xdddddddd.


10 years ago
Whiteboard: [sg:critical]
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Flags: blocking1.9.1+ → wanted1.9.1+
Flags: wanted1.9.1+ → blocking1.9.1+
The attached testcase crashes my linux mozilla-central debug build, for the reason bz mentioned in comment 1.

OS/Platform --> All.
OS: Mac OS X → All
Hardware: PC → All
Assignee: jag → roc
Using a fresh nsFrameConstructorState when we construct the new frames is easy, and we don't crash anymore.

But we end up in a bad state where we have an assertion "Popup containing block is missing" ... that assertion is supposed to be suppressed if there's a root box, but there is in this case. Perhaps the problem there is that we decide to use NS_NewRootBoxFrame instead of NS_NewCanvasFrame based on whether the root element is a XUL element, instead of checking its display type. In any case, that's an existing bug on trunk, so I've filed it as bug 464409 and carry on with my patch for this bug here.
Created attachment 347717 [details] [diff] [review]
Attachment #347717 - Flags: superreview?(bzbarsky)
Attachment #347717 - Flags: review?(bzbarsky)
Comment on attachment 347717 [details] [diff] [review]

Looks good.
Attachment #347717 - Flags: superreview?(bzbarsky)
Attachment #347717 - Flags: superreview+
Attachment #347717 - Flags: review?(bzbarsky)
Attachment #347717 - Flags: review+
Whiteboard: [sg:critical] → [sg:critical][needs landing]
Landed on mozilla-central (and thus also on mozilla-1.9.1):
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [sg:critical][needs landing] → [sg:critical]
Target Milestone: --- → mozilla1.9.1b3
Flags: in-testsuite+
No longer blocks: 457213
Duplicate of this bug: 457213
Keywords: fixed1.9.1
Verified fixed with builds on OS X and Windows (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090204 Shiretoko/3.1b3pre ID:20090204020327)
Keywords: fixed1.9.1 → verified1.9.1
Crash Signature: [@ nsCSSFrameConstructor::ConstructXULFrame]
Group: core-security
You need to log in before you can comment on or make changes to this bug.