118465 - Site causes infinite loope that swallows all system memory

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Peter]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122106

Not much to say. Mozilla crashes and won't display the page and leaks memory.
Check it out.

Reproducible: Always
Steps to Reproduce:
1. Enter the URL http://www.mellow.dk/book/
2. Press enter


Actual Results:  Infinite loop that consumes all system memory

Expected Results:  Should display page.

I've experienced this both K-meleon (based on 0.9.5), Linux Mandrake 8.0 with
Mozilla 0.9.5 and 0.9.7 and Win2k Mozilla 0.9.7

Comment 1

[gavin long]

Yup, hangs me, too.  Win98SE, 2002010403

Comment 2

[Olivier Cahagne]

confirming on Win2k with build 2002010508.
It hangs Mozilla, therefore, memory usage remains around 10-20MB, and CPU under 30%.

Comment 3

[Peter]

I've found that 

http://www.mellow.dk/book/book.php?css=transparent

also crashes Mozilla. It works fine in MSIE.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Anyone care to get a stack trace so this can get assigned to a useful 
component?  (Confirming bugs while leaving them in Browser-General is the 
surest way to make sure that no one gets to them for a while.... at least UNCO 
bugs get triaged fairly often..)

Comment 5

[Ludovic Hirlimann]

Platform should be ALL, since I can reproduce on MacOSX build ID 2002010308

Comment 6

[Olav Vitters]

Attachment: Stacktrace of all threads

Created a stracktrace. At this time Mozilla was using 420MB of memory. Using
Linux, CVS was build today.

Comment 7

[Olivier Cahagne]

Attachment: HTML page that crashes Mozilla (saved from http://www.mellow.dk/book/book.php?css=transparent via sniffer)

Comment 8

[Olivier Cahagne]

Attachment: Reduced testcase that will hang Mozilla (tested with 2002010508 on Win2k, I killed it after it took 1.4GB of RAM/VM)

From above testcase, Mozilla goes nuts when he sees both of the following:
 - CSS with body { DISPLAY : table-header-group; }
 - <table></table> in the html body

Didn't look for dupes, might be a memory leak ?

Comment 9

[Olivier Cahagne]

Trying 'Layout' component as it seems to be related to CSS (
http://www.w3.org/TR/REC-CSS2/tables.html ).
It could also belong to 'Style System' ?

Comment 10

[Peter]

FYI : Both index.php and book.php page crashes Mozilla in the same manner. The
pages are pretty simple HTML, so I have reason to believe that it maybe in the
page header that Mozilla breaks : It sets a cookie. The following is the PHP (I
think is version 4 on the server) header manipulation :

index.php 
Here I relocate ppl to book.php if they have the cookie "css" set and do not
have the variable "edit" set) :

<?php 
if(isset($arrCookie["css"]) && !isset($edit)) {
	header("Location: book.php");
	exit;
}
header ("Expires: Mon, 26 Jul 1997 05:00:00 GMT");    // Date in the past
header ("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");  // always modified
header ("Cache-Control: no-cache, must-revalidate");  // HTTP/1.1
header ("Pragma: no-cache");                          // HTTP/1.0
      
?> 
.e
.t
.c

book.php :
Set the cookie if given right parameters

<?php
if(isset($css) || isset($newsstring)) {
	$newsstring = str_replace(" ","",$newsstring);
	setcookie("arrCookie[css]",$css,(time()+time()),"/","www.mellow.dk");
	  setcookie("arrCookie[newsstring]",$newsstring,(time()+time()),"/","www.mellow.dk");
	$arrCookie["css"] = $css; // so arrCookie !empty 1st time
	$arrCookie["newsstring"] = $newsstring; 
}
.e
.t
.c

Comment 11

[Peter]

Sorry - ignore my last post about the possible header problems.
Olivier Cahagne is right in Comment #8

Here is the index page whitout the CSS with body { DISPLAY : table-header-group; } :

http://www.mellow.dk/book/moz-test.php

Works fine - sorry.

Comment 12

[Kevin McCluskey (gone)]

confirm hang using 2002012203 build on WINXP.
Reassigning to Karnaze

Comment 13

[Denis Antrushin]

Mozilla falls into infinite loop in nsBlovkFrame::AddFrame().
At some point newFrame->mNextSibling points to itself so we never
get out of 
while (newFrame) {
....
newFrame->GetNextSibling(&newFrame);
}

Comment 14

[Denis Antrushin]

I found that nsCSSFrameConstructor sometimes inserts the same frame into
aState.mPseudoFrames.mCellInner.mChildList twice.
First time nsIFrame is inserted in nsCSSFrameConstructor::ConstructTableFrame
line 2328:
    if (aIsPseudoParent) {
      aState.mPseudoFrames.mCellInner.mChildList.AddChild(aNewOuterFrame);
    }
(called from nsCSSFrameConstructor::ConstructFrameByDisplayType() - line 6249).
Then we jump to 'nearly_done' label, where the same frame is inserted second
time (line 6373):
  else if (nsnull != newFrame) {
    // Add the frame we just created to the flowed list
    frameItems.AddChild(newFrame);                   <------ NB!!!!!!!!!
    if (newBlock) {
      frameItems.AddChild(newBlock);
      if (nextInline) {
        frameItems.AddChild(nextInline);
      }
    }
  }

After this, mNextSibling of given nsIFrame points back to itself :-)

Comment 15

[Denis Antrushin]

Attachment: propesed patch, v1

Don't insert the same frame twice

Comment 16

[Boris Zbarsky [:bzbarsky]]

ccing David to look at the nsCSSFrameConstructor issues (And review the patch?)

Comment 17

[karnaze (gone)]

Comment on attachment 66734 [details] [diff] [review]
propesed patch, v1

r=karnaze, if it passes the table regression tests (which include a few
anonymous frames tests)

Comment 18

[anthonyd]

this patch got its 'r=', has it passed the regression tests?

Comment 19

[Denis Antrushin]

Where I can find those tests?

Comment 20

[Kevin McCluskey (gone)]

Marking nsbeta1+

Comment 21

[Marc Attinasi]

*** Bug 123490 has been marked as a duplicate of this bug. ***

Comment 22

[Marc Attinasi]

I have tested this patch in teh context of bug 123490 (the same problem,
infinite loop due to GetNextSibling returning the same frame).

I do no see how this should require table regression tests - the code before the
patch was just wrong (it is never correct to add the same into the child list
twice).

Comment 23

[Marc Attinasi]

Comment on attachment 66734 [details] [diff] [review]
propesed patch, v1

sr=attinasi

Comment 24

[karnaze (gone)]

This code involves anonymous frames, and although in this bug, a frame is 
getting added twice, we need to make sure that in other cases, it gets added at 
least once. I'll run the regression tests.

Comment 25

[karnaze (gone)]

The patch is in. Thanks Denis!

Comment 26

[Marc Attinasi]

BTW: I'd like to add some debug code to make sure that a frame is not in the
child list twice, to catch this type of problem more easily.  Is there any case
where the same frame *should* be in a child list twice? I cannot think of any,
and because we chain via the nextSibling pointer, it would introduce a
circularity, always.

Comment 27

[Bob Kanefsky]

Bug #118465 is fixed, but Bug #123490 is not.

Mozilla 0.9.8 (build 2002020405)
  - hangs on Attachment #63752 [details] (Bug #118465)
  - hangs on Attachment #63754 [details] (Bug #118465)
  - crashes or hangs on Attachment #67870 [details] (Bug #123490) with enough clicking

Nightly build 2002021303
  - works on Attachment #63752 [details] (Bug #118465)
  - works on Attachment #63754 [details] (Bug #118465)
  - crashes on Attachment #67870 [details] (Bug #123490) with a few clicks -- TB2893529M