Closed Bug 454751 Opened 16 years ago Closed 16 years ago

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

Categories

(Core :: XUL, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.1b3

People

(Reporter: jruderman, Assigned: roc)

References

Details

(Keywords: crash, testcase, verified1.9.1, Whiteboard: [sg:critical])

Crash Data

Attachments

(2 files)

No description provided.
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-
Indeed, today I found a related testcase that causes nsCSSFrameConstructor::ConstructFrameInternal to call 0xdddddddd.
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
Blocks: 457213
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.
Attached patch fix (deleted) — Splinter Review
Attachment #347717 - Flags: superreview?(bzbarsky)
Attachment #347717 - Flags: review?(bzbarsky)
Comment on attachment 347717 [details] [diff] [review] fix 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): http://hg.mozilla.org/mozilla-central/rev/feb0232b6771
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [sg:critical][needs landing] → [sg:critical]
Target Milestone: --- → mozilla1.9.1b3
Flags: in-testsuite+
No longer blocks: 457213
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)
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsCSSFrameConstructor::ConstructXULFrame]
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: