Closed
Bug 454751
Opened 16 years ago
Closed 16 years ago
Crash [@ nsCSSFrameConstructor::ConstructXULFrame] with treecols, display:table
Categories
(Core :: XUL, defect, P2)
Core
XUL
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)
(deleted),
application/vnd.mozilla.xul+xml
|
Details | |
(deleted),
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
No description provided.
Comment 1•16 years ago
|
||
In nsCSSFrameConstructor::ConstructXULFrame we have aState.mPopupItems.containingBlock pointing to a deleted frame.
Comment 2•16 years ago
|
||
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?
Reporter | ||
Comment 4•16 years ago
|
||
Indeed, today I found a related testcase that causes nsCSSFrameConstructor::ConstructFrameInternal to call 0xdddddddd.
Reporter | ||
Updated•16 years ago
|
Whiteboard: [sg:critical]
Assignee | ||
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Assignee | ||
Updated•16 years ago
|
Flags: blocking1.9.1+ → wanted1.9.1+
Assignee | ||
Updated•16 years ago
|
Flags: wanted1.9.1+ → blocking1.9.1+
Comment 5•16 years ago
|
||
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 | ||
Updated•16 years ago
|
Assignee: jag → roc
Assignee | ||
Comment 6•16 years ago
|
||
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.
Assignee | ||
Comment 7•16 years ago
|
||
Attachment #347717 -
Flags: superreview?(bzbarsky)
Attachment #347717 -
Flags: review?(bzbarsky)
Comment 8•16 years ago
|
||
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+
Assignee | ||
Updated•16 years ago
|
Whiteboard: [sg:critical] → [sg:critical][needs landing]
Comment 9•16 years ago
|
||
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
Assignee | ||
Updated•16 years ago
|
Flags: in-testsuite+
Updated•16 years ago
|
Keywords: fixed1.9.1
Comment 11•16 years ago
|
||
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
Keywords: fixed1.9.1 → verified1.9.1
Updated•13 years ago
|
Crash Signature: [@ nsCSSFrameConstructor::ConstructXULFrame]
Updated•12 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•