Closed Bug 683702 Opened 9 years ago Closed 9 years ago

Crash [@ nsFrame::DestroyFrom] with position: absolute; -moz-column-count: 2;


(Core :: Layout, defect)

Not set





(Reporter: martijn.martijn, Assigned: dholbert)


(Blocks 1 open bug)


(Keywords: crash, regression, testcase)

Crash Data


(2 files)

Attached file testcase
See testcase, which crashes current trunk build after 100ms.

I assume this is a regression (in the end, everything is a regression).
There is bug 673931, which might be the same, that would indicate this bug also occurs in Firefox 5, at least.
0 	xul.dll 	nsFrame::DestroyFrom 	
1 	xul.dll 	nsBlockFrame::DestroyFrom 	layout/generic/nsBlockFrame.cpp:344
2 	xul.dll 	nsBlockFrame::DestroyFrom 	layout/generic/nsBlockFrame.cpp:344
3 	xul.dll 	nsBlockFrame::DestroyFrom 	layout/generic/nsBlockFrame.cpp:322
4 	xul.dll 	nsBlockFrame::DeleteNextInFlowChild 	
5 	xul.dll 	nsIFrame::Destroy 	layout/generic/nsIFrame.h:569
6 	xul.dll 	nsPlaceholderFrame::DestroyFrom 	layout/generic/nsPlaceholderFrame.cpp:169
7 	xul.dll 	nsBlockFrame::DestroyFrom 	layout/generic/nsBlockFrame.cpp:322
8 	xul.dll 	nsContainerFrame::DestroyFrom 	layout/generic/nsContainerFrame.cpp:270
9 	xul.dll 	nsContainerFrame::DestroyFrom 	layout/generic/nsContainerFrame.cpp:270
10 	xul.dll 	nsContainerFrame::DestroyFrom 	layout/generic/nsContainerFrame.cpp:270
11 	xul.dll 	nsContainerFrame::DestroyFrom 	layout/generic/nsContainerFrame.cpp:270
12 	xul.dll 	nsTableFrame::DestroyFrom 	layout/tables/nsTableFrame.cpp:269
13 	xul.dll 	nsContainerFrame::DestroyFrom 	layout/generic/nsContainerFrame.cpp:270
14 	xul.dll 	nsTableOuterFrame::DestroyFrom 	layout/tables/nsTableOuterFrame.cpp:218
15 	xul.dll 	nsIFrame::Destroy 	layout/generic/nsIFrame.h:569
16 	xul.dll 	nsBlockFrame::DoRemoveFrame 	layout/generic/nsBlockFrame.cpp:5442
17 	xul.dll 	nsBlockFrame::RemoveFrame 	layout/generic/nsBlockFrame.cpp:5011
18 	xul.dll 	nsCSSFrameConstructor::ContentRemoved 	layout/base/nsCSSFrameConstructor.cpp:7516
19 	xul.dll 	nsCSSFrameConstructor::RecreateFramesForContent 	layout/base/nsCSSFrameConstructor.cpp:9091
20 	xul.dll 	nsCSSFrameConstructor::WipeContainingBlock 	
Regression window using mozilla-central Linux64 builds:
which makes me suspect "c6e432ffd5e2	Daniel Holbert — Bug 679933: When a frame is destroyed, remove next special-sibling's pointer to it. r=roc"

Summary is similar to "Bug 682649 - Crash with rel&abs pos, -moz-column"
Blocks: 679933
OS: Windows 7 → All
Hardware: x86 → All
Yup, regression from bug 679933 (at least, it crashes while inside the code added there).

A bit odd, though.  Here's part of the code that bug added to nsFrame::Destroy:
>+++ b/layout/generic/nsFrame.cpp
>+  if (mState & NS_FRAME_IS_SPECIAL) {
>+    nsIFrame* nextSib = static_cast<nsIFrame*>
>+      (Properties().Get(nsIFrame::IBSplitSpecialSibling()));
>+    if (nextSib) {
>+      NS_WARN_IF_FALSE(this ==
>+         nextSib->Properties().Get(nsIFrame::IBSplitSpecialPrevSibling()),
>+         "Next-sibling / prev-sibling chain is inconsistent");

In this bug's testcase, we hit that line with |nextSib| being non-null -- however, it points to a destroyed frame (whose member data is all set to 0x7ffffffff0dea7ff or thereabouts).
So, bug 679933 was a case where an element's *next* IB sibling was outliving it, and so we needed to proactively clear that sibling's pointer.

This appears to be the same problem, except here, the *previous* IB sibling is the one that's living longer.

I imagine it'd be sufficient if we extended the chunk referenced in comment 2 to clear the pointer-to-ourself in *both* the prev & next siblings.
Attached patch fix v1Splinter Review
(fix along the lines of comment 3)

This fixes the testcase here as well as the one from bug 682649.  I've included both of them as crashtests.
Attachment #557362 - Flags: review?(roc)
Assignee: nobody → dholbert
Flags: in-testsuite+
Whiteboard: [inbound]
Duplicate of this bug: 682649
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla9
Verified fixed, using current trunk build.
You need to log in before you can comment on or make changes to this bug.