315850 - Evil testcase crashes [@ GetNearestContainingBlock] Mozilla

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

See upcoming testcase.
It crashes current trunk Mozilla build. It also crashes Mozilla1.7, so no recent regression.

Talkback ID: TB11671484G

GetNearestContainingBlock  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsHTMLReflowState.cpp, line 660]
nsHTMLReflowState::InitAbsoluteConstraints  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsHTMLReflowState.cpp, line 1049]
nsHTMLReflowState::InitConstraints  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsHTMLReflowState.cpp, line 1965]
nsHTMLReflowState::Init  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsHTMLReflowState.cpp, line 342]
nsHTMLReflowState::nsHTMLReflowState  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsHTMLReflowState.cpp, line 315]
nsAbsoluteContainingBlock::ReflowAbsoluteFrame  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsAbsoluteContainingBlock.cpp, line 521]
nsAbsoluteContainingBlock::IncrementalReflow  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsAbsoluteContainingBlock.cpp, line 387]
ViewportFrame::Reflow  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsViewportFrame.cpp, line 290]
IncrementalReflow::Dispatch  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 859]
PresShell::ProcessReflowCommands  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6483]
ReflowEvent::HandleEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6308]
PL_HandleEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/xpcom/threads/plevent.c, line 689]
SHELL32.dll + 0x520c24 (0x778b0c24)

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase (crashes on load)

Comment 2

[Boris Zbarsky [:bzbarsky]]

So sometime part way through the initial reflow (which is stupid, since XUL is involved and XUL invokes initial reflow multiple times on its kids!), we get:

###!!! ASSERTION: bad status: 'NS_FRAME_IS_COMPLETE(aStatus)', file ../../../mozilla/layout/generic/nsFrame.cpp, line 5305

(this is at the end of nsFrame::BoxReflow).  After that, we get:

###!!! ASSERTION: overflow list is not empty for initial reflow: '!overflowFrames', file ../../../mozilla/layout/generic/nsInlineFrame.cpp, line 375

At which point the relevant part of the frame model looks like this:

                Inline(span)(1)@0x88c064c next=0x88c70b4 {0,0,1,238} [state=00000001] [content=0x88c21d8] [sc=0x88c05fc]<
                  Text(0)@0x88c06d4[0,4,T]  next=0x88c07ec {0,0,0,0} [state=51000020] sc=0x88c0684 pst=:-moz-non-element<
                    "\n   "
                  >
                  Block(span)(1)@0x88c07ec next=0x88c0840 {0,0,0,0} sc=0x88c0740(i=0,b=0)<
                  >
                  Text(2)@0x88c0840[0,5,T]  next=0x88c6c10 {0,0,0,0} [state=51000020] sc=0x88c0684 pst=:-moz-non-element<
                    "\n    "
                  >
                  Placeholder(span)(3)@0x88c6c10 {0,0,0,0} outOfFlowFrame=Area(span)(3)@0x88c6bbc
                  Text(4)@0x88c6e14[0,6,T]  next=0x88c6ea4 {0,0,0,0} [state=51000020] sc=0x88c0684 pst=:-moz-non-element<
                    "\n     "
                  >
                  Frame(br)(5)@0x88c6ea4 {0,0,1,238} [state=00000020] [content=0x88c2490]
                >
                Overflow-list<
                  Text(6)@0x88c6ed0[0,0,F]  next=0x88c703c {0,0,0,0} [state=00000422] sc=0x88c0684 pst=:-moz-non-element<
                    ""
                  >
                  Placeholder(div)(7)@0x88c703c {0,0,0,0} [state=00000402] outOfFlowFrame=Area(div)(7)@0x88c6fe8
                  Text(8)@0x88c7074[0,0,F]  {0,0,0,0} [state=00000422] sc=0x88c0684 pst=:-moz-non-element<
                    ""
                  >
                >

So it looks like we lose the placeholder for the fixed-pos div.  And then later when we look for it in the absolute constraints code we get null and crash.

The simplest solution, of course, is to not have multiple initial reflows.  Here's hoping the reflow branch does that!

Comment 3

[Adam Guthrie]

This got fixed sometime between 2005-12-15 05:00 and 2005-12-16 05:00. 

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-12-15+04%3A00&maxdate=2005-12-16+06%3A00&cvsroot=%2Fcvsroot

Comment 4

[Boris Zbarsky [:bzbarsky]]

Maybe by the patch for bug 307992?

Comment 5

[Martijn Wargers (dead)]

So can this be marked fixed/worksforme?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Yeah, WFM.  I get no asserts either.

Comment 7

[François Gagné]

This seems to have regressed on 1.8 Branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/20080202 BonEcho/2.0.0.12pre ID:2008020204

The testcase https://bugzilla.mozilla.org/attachment.cgi?id=202499 crash with a new empty profile.

(Bug 415369 lead me here because from time to time I'm crashing loading Gmail with [@ GetNearestContainingBlock] on top of stack)

Comment 8

[Boris Zbarsky [:bzbarsky]]

> This seems to have regressed on 1.8 Branch

I don't think anyone ever claimed that this was fixed on the branch....

Comment 9

[François Gagné]

Ok, thanks, I wasn't sure if Trunk in 2005 meant 1.9

I've done some testing and indeed Firefox 2.0 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0) crash on the testcase :(

Should this be reopened for 1.8 branch?

Comment 10

[Martijn Wargers (dead)]

I don't think it should be reopened for the 1.8 branch, unless the intention really is to fix it on branch.

Comment 11

[Martijn Wargers (dead)]

Oh sorry, not reading your previous comment well, you were talking about bug 415369, about GMail crashing Firefox with the same stack. That would indeed be a good reason to try and fix it on branch (at least, if it's reproducable).

Comment 12

[Daniel Veditz [:dveditz]]

Not exactly reproducible, but it does seem to occur fairly often for François judging from the talkback reports.

Comment 13

[François Gagné]

It's not the exact same stack, but the top 6 frames are the same as Bug 415369

GetNearestContainingBlock
nsHTMLReflowState::InitAbsoluteConstraints
nsHTMLReflowState::InitConstraints
nsHTMLReflowState::Init
nsHTMLReflowState::nsHTMLReflowState
nsAbsoluteContainingBlock::ReflowAbsoluteFrame

Comment 14

[Boris Zbarsky [:bzbarsky]]

"Trunk" started to mean 1.9 in August 2005...

And if you feel that this should be fixed on the branch, nominate it for branch blocking.  The status indicates what it is on the trunk, so it shouldn't be reopened, since on trunk the bug is no more.

Comment 15

[Daniel Veditz [:dveditz]]

This bug itself doesn't block the branch, it was nominated because it was a reproducible testcase that crashes at the same location as a new (for 2.0.0.12) topcrash (bug 415369 -- which we _do_ still want on the branch).