1213836 - Crash at nsIFrame::StyleDisplay nsLayoutUtils::GetFloatFromPlaceholder nsLineLayout::ReflowFrame nsBlockFrame::ReflowInlineFrame nsBlockFrame::DoReflowInlineFrames

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect)

Description

[Carsten Book [:Tomcat]]

Attachment: bughunter crash stack

Found via bughunter and reproduced on a windows 7 trunk debug build based on m-c tip

Str:

-> Load http://live.hundeland.de/classic-dog-rinderjumboknochen-19849.html
--> Crash at nsIFrame::StyleDisplay nsLayoutUtils::GetFloatFromPlaceholder nsLineLayout::ReflowFrame nsBlockFrame::ReflowInlineFrame nsBlockFrame::DoReflowInlineFrames

Comment 1

[Carsten Book [:Tomcat]]

Botond, would this be something for you ?

Comment 2

[Botond Ballo [:botond]]

As this concerns reflow code, :dholbert might be able to comment.

Comment 3

[Daniel Holbert [:dholbert]]

mozregression gives me the following mozilla-central range:
 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0bb4773db082&tochange=eb2f5c66561b

...and the attached backtrace shows that we're in nsColumnSetFrame methods at several levels.  Tentatively blaming bug 822053.

Comment 4

[Daniel Holbert [:dholbert]]

In a debug build, I get many copies of these assertions just before the crash:
[Child 14008] ###!!! ASSERTION: frame tree not empty, but caller reported complete status: 'aSubtreeRoot->GetPrevInFlow()', file layout/base/nsLayoutUtils.cpp, line 7058

[Child 14008] ###!!! ASSERTION: frame tree not empty, but caller reported complete status: 'start == end || IsInLetterFrame(aSubtreeRoot)', file layout/base/nsLayoutUtils.cpp, line 7072
}

...and then one instance of each of the following two assertions:
{
[Child 14008] ###!!! ASSERTION: Placeholder relationship should have been torn down already; this might mean we have a stray placeholder in the tree.: '!placeholder || nsLayoutUtils::IsProperAncestorFrame(aDestructRoot, placeholder)', file layout/generic/nsFrame.cpp, line 641
[Child 14008] ###!!! ASSERTION: Null out-of-flow for placeholder?: 'outOfFlow', file layout/style/../generic/nsPlaceholderFrame.h, line 160
}

Comment 5

[Daniel Holbert [:dholbert]]

...and (in my debug build) ultimately we crash when evaluating the condition for the assertion here:
> 1406 nsIFrame*
> 1407 nsLayoutUtils::GetFloatFromPlaceholder(nsIFrame* aFrame) {
> 1408   NS_ASSERTION(nsGkAtoms::placeholderFrame == aFrame->GetType(),
> 1409                "Must have a placeholder here");
> 1410   if (aFrame->GetStateBits() & PLACEHOLDER_FOR_FLOAT) {
> 1411     nsIFrame *outOfFlowFrame =
> 1412       nsPlaceholderFrame::GetRealFrameForPlaceholder(aFrame);
> 1413     NS_ASSERTION(outOfFlowFrame->IsFloating(),
> 1414                  "How did that happen?");

'outOfFlowFrame' is null here, so we crash inside of outOfFlowFrame->IsFloating()'s call to nsIFrame::StyleDisplay().

In an opt build, we crash in a slightly different place (because we don't evaluate this NS_ASSERTION expression):
 bp-d038682e-1420-4806-a437-6784f2151013
 [@ mozilla::layout::FrameChildListIterator::FrameChildListIterator(nsIFrame const*) ]

The debug backtrace is likely more useful, though (plus we've tripped over so many assertions at that point, stuff's already been pretty broken for a while).

A reduced testcase would help out a lot here -- adding "qawanted".  I suspect this boils down to a tricky combination of "-moz-column-*" and "float" (and it may be a dupe of some other bug).

Comment 6

[Jesse Ruderman]

"Server not found". Anyone have a cached copy?

Comment 7

[Daniel Holbert [:dholbert]]

I don't, and it doesn't look like anyone else has looked at this closely enough to have saved a cached version.

On the bright (?) side, though: per end of comment 5, it's possible (maybe likely) that this was a dupe (or a newly-activated way of triggering) an already-filed moz-column + float interaction bug -- e.g. bug 864972 or bug 718331.

I guess I'll resolve this as INCOMPLETE since we lost access to the testcase, anyway.