Closed
Bug 399843
Opened 17 years ago
Closed 17 years ago
"ASSERTION: overflow containers out of order or bad parent" and crash with -moz-column, overflowing height
Categories
(Core :: Layout, defect, P3)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jruderman, Assigned: fantasai.bugs)
References
Details
(Keywords: assertion, crash, testcase, Whiteboard: [sg:critical][dbaron-1.9:RsCo])
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
Loading the testcase triggers:
###!!! ASSERTION: overflow containers out of order or bad parent: '!(aOverflowCont->GetStateBits() & NS_FRAME_IS_OVERFLOW_CONTAINER)', file /Users/jruderman/trunk/mozilla/layout/generic/nsContainerFrame.cpp, line 1379
###!!! ASSERTION: Placeholder relationship should have been torn down; see comments in nsPlaceholderFrame.h: '!shell->FrameManager()->GetPlaceholderFrameFor(mOutOfFlowFrame)', file /Users/jruderman/trunk/mozilla/layout/generic/nsPlaceholderFrame.cpp, line 132
###!!! ASSERTION: frame was not removed from primary frame map before destruction or was readded to map after being removed: 'Not Reached', file /Users/jruderman/trunk/mozilla/layout/base/nsFrameManager.cpp, line 707
###!!! ASSERTION: Dead placeholder in placeholder map: 'entry->placeholderFrame->GetOutOfFlowFrame() != (void*)0xdddddddd', file /Users/jruderman/trunk/mozilla/layout/base/nsFrameManager.cpp, line 134
###!!! ASSERTION: no placeholder frame: 'nsnull != placeholderFrame', file /Users/jruderman/trunk/mozilla/layout/generic/nsHTMLReflowState.cpp, line 1098
Crash at one of the following:
[@ nsIFrame::GetParent]
[@ nsFrameManager::CaptureFrameStateFor]
[@ nsPropertyTable::PropertyList::Equals]
[@ nsFrameList::Destroy]
[@ nsFrameManager::GetPlaceholderFrameFor]
Some of the crashes look [sg:critical].
Flags: blocking1.9?
Reporter | ||
Updated•17 years ago
|
Whiteboard: [sg:critical]
Flags: blocking1.9? → blocking1.9+
Updated•17 years ago
|
OS: Mac OS X → All
fantasai, can you take this and assign it to yourself?
Updated•17 years ago
|
Whiteboard: [sg:critical] → [sg:critical][dbaron-1.9:RsCo]
Priority: -- → P3
The Out-of-Order assertion is getting triggered where we have an overflow containers list in which the next-in-flow has its prev-in-flow as a nextsibling. Haven't yet figured out why.
Jesse - just for future reference, the out-of-order assertion by itself means we have a major problem showing up in this code. It's unlikely that it will /not/ result in a crash.
Status: NEW → ASSIGNED
This code should never pull and insert from the same list. The problem was it wasn't expecting to pull from the overflowContainers list into the same parent's excessOverflowContainers list.
Attachment #288787 -
Flags: superreview?(roc)
Attachment #288787 -
Flags: review?(roc)
Attachment #288787 -
Flags: superreview?(roc)
Attachment #288787 -
Flags: superreview+
Attachment #288787 -
Flags: review?(roc)
Attachment #288787 -
Flags: review+
Fix checked in. nsContainerFrame.cpp rev 1.292
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: in-testsuite?
Reporter | ||
Comment 5•17 years ago
|
||
Loading the testcase in a 1.8 branch build doesn't cause any assertion failures.
Group: security
Flags: wanted1.8.1.x-
You need to log in
before you can comment on or make changes to this bug.
Description
•