211183 - Infinite loop in nsBlockFrame::DoRemoveFrame

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect)

Description

[timeless]

My build is a bit old, I was trying to enter a comment in the slashdot 
netscape7.1 release article. my build is a relatively normal opt profile build 
although it does have various debug things enabled. for some reason mozillas on 
my system have to deal with resource shortages (mostly gdi i suppose, there 
should be enough vm). for some reason any text area (e.g. a plain text message) 
with whitespace may end up being approximately infinitely long. and iframes 
have a tendency not to paint (resulting in garbage). while i was typing in the 
edit box the caret became approximately infinitely tall. there was no 
interesting -console output, but i'm going to copy the output here just for the 
record:

Document http://slashdot.org/comments.pl?sid=69402&cid=6332470 loaded 
successfully
Parse Time (this=1B8D4CE0): Real time 0:0:0.10, CP time 0.010
DTD Time: Real time 0:0:0.0, CP time 0.000
Tokenize Time: Real time 0:0:0.10, CP time 0.010
Parse Time (this=1B912320): Real time 0:0:0.20, CP time 0.020
DTD Time: Real time 0:0:0.0, CP time 0.000
Tokenize Time: Real time 0:0:0.20, CP time 0.020
Parse Time (this=1B93A670): Real time 0:0:0.20, CP time 0.020
DTD Time: Real time 0:0:0.0, CP time 0.000
Tokenize Time: Real time 0:0:0.20, CP time 0.020
Content creation time (this=1AD61AB0): Real time 0:0:0.210, CP time 0.220
Reflow time (this=1AD712D0): Real time 0:0:0.0, CP time 0.000
Frame construction plus style resolution time (this=1AD712D0): Real time 
0:0:0.541, CP time 0.431
Style resolution time (this=1AD712D0): Real time 0:0:0.100, CP time 0.130
Parse Time (this=1AD61DF0): Real time 0:0:0.220, CP time 0.170
DTD Time: Real time 0:0:0.231, CP time 0.160
Tokenize Time: Real time 0:0:0.40, CP time 0.040
Document http://slashdot.org/comments.pl?
sid=69402&op=Reply&threshold=1&commentsort=0&tid=114&mode=thread&pid=6332470 
loaded successfully

There was a deCOM in mozilla/layout/html/base/src/nsBlockFrame.cpp in rev 3.577 
which is the current rev, but it did not change the meaning of the code.

Anyway, here's the complete loop in nsBlockFrame::DoRemoveFrame as seen in 
msdev by step over (relevant variables listed in comments before the code which 
checks them)
  /* +aDeletedFrame  0x0470b0b0 */
  while (nsnull != aDeletedFrame) {
    /* +  line.mCurrent  0x108c62c4
       +  line_end.mCurrent  0x108c62c4 */
    while ((line != line_end) && (nsnull != aDeletedFrame)) {
    /* +  flow  0x00000000 */
    if (flow && aDeletedFrame) {
  }

fwiw:
-	(nsSplittableFrame*)this	0x108c628c
|+	[nsAreaFrame]	{...}
|+	nsFrame	{...}
|+	mPrevInFlow	0x00000000
\+	mNextInFlow	0x00000000

+	aDeletedFrame->mRect	{x=0 y=858854580 width=360 height=273918300}

(yes, i really do believe mozilla thought that the rectangle had those 
dimensions).

please don't worry too much about the dimensions. The fact that the infinite 
loop was reachable and that the code really doesn't prevent it is the more 
critical bug.

Had this been a debug build, i would have found out about bug 56894 because of 
this code:
      flow = (nsBlockFrame*) flow->mNextInFlow;
      NS_ASSERTION(nsnull != flow, "whoops, continuation without a parent");
which by my calculations would have triggered once, the first time through the 
loop.

I suspect i've actually hit this before in debug builds.

I think I'm going to suggest some wallpaper because i don't like infinite loops.

Comment 1

[timeless]

Attachment: wallpaper

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 126796 [details] [diff] [review]
wallpaper

r+sr=dbaron if you follow the local bracing style (use {}) and attach a diff
with a sane number of lines of context (6-12?)

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Also, could you file a separate bug with a testcase for the assertion?  (Is it
block-within-inline splitting?)

Comment 4

[timeless]

Attachment: same wallpaper -u6 w/ local style braces

Comment 5

[timeless]

sorry I have no idea how to generate testcases for this stuff. i just break
stuff and do simplistic analysis. the page was definitely the one listed in this
bug, but the trick probably related to the near infinite height and possibly to
typing/pressing backspace/delete or pasting, it's really hard to type when you
can't see what you're typing (e.g. right now).

Comment 6

[timeless]

checked in
qa should verify by lxr/code inspection