Last Comment Bug 118465 - Site causes infinite loope that swallows all system memory
: Site causes infinite loope that swallows all system memory
Status: VERIFIED FIXED
[awd:tbl][p3][r=]
: hang, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
-- critical (vote)
: mozilla0.9.9
Assigned To: karnaze (gone)
: Chris Petersen
: Sean Voisen (:svoisen) [On parental leave Nov 15 - Jan 7]
Mentors:
http://www.mellow.dk/book/
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-06 11:14 PST by Peter
Modified: 2002-02-13 23:09 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Stacktrace of all threads (7.13 KB, text/plain)
2002-01-06 12:35 PST, Olav Vitters
no flags Details
HTML page that crashes Mozilla (saved from http://www.mellow.dk/book/book.php?css=transparent via sniffer) (47.03 KB, text/html)
2002-01-06 13:58 PST, Olivier Cahagne
no flags Details
Reduced testcase that will hang Mozilla (tested with 2002010508 on Win2k, I killed it after it took 1.4GB of RAM/VM) (185 bytes, text/html)
2002-01-06 14:18 PST, Olivier Cahagne
no flags Details
propesed patch, v1 (669 bytes, patch)
2002-01-28 06:12 PST, Denis Antrushin
karnaze: review+
attinasi: superreview+
Details | Diff | Splinter Review

Description User image Peter 2002-01-06 11:14:27 PST
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 User image gavin long 2002-01-06 11:25:11 PST
Yup, hangs me, too.  Win98SE, 2002010403
Comment 2 User image Olivier Cahagne 2002-01-06 11:26:09 PST
confirming on Win2k with build 2002010508.
It hangs Mozilla, therefore, memory usage remains around 10-20MB, and CPU under 30%.
Comment 3 User image Peter 2002-01-06 11:29:05 PST
I've found that 

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

also crashes Mozilla. It works fine in MSIE.
Comment 4 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2002-01-06 11:59:41 PST
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 User image Ludovic Hirlimann 2002-01-06 12:01:37 PST
Platform should be ALL, since I can reproduce on MacOSX build ID 2002010308
Comment 6 User image Olav Vitters 2002-01-06 12:35:25 PST
Created attachment 63747 [details]
Stacktrace of all threads

Created a stracktrace. At this time Mozilla was using 420MB of memory. Using
Linux, CVS was build today.
Comment 7 User image Olivier Cahagne 2002-01-06 13:58:55 PST
Created attachment 63752 [details]
HTML page that crashes Mozilla (saved from http://www.mellow.dk/book/book.php?css=transparent via sniffer)
Comment 8 User image Olivier Cahagne 2002-01-06 14:18:12 PST
Created attachment 63754 [details]
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 User image Olivier Cahagne 2002-01-06 14:30:04 PST
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 User image Peter 2002-01-06 17:14:46 PST
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 User image Peter 2002-01-06 17:35:40 PST
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 User image Kevin McCluskey (gone) 2002-01-23 12:11:40 PST
confirm hang using 2002012203 build on WINXP.
Reassigning to Karnaze
Comment 13 User image Denis Antrushin 2002-01-25 10:37:32 PST
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 User image Denis Antrushin 2002-01-28 05:59:52 PST
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 User image Denis Antrushin 2002-01-28 06:12:11 PST
Created attachment 66734 [details] [diff] [review]
propesed patch, v1

Don't insert the same frame twice
Comment 16 User image Boris Zbarsky [:bzbarsky, bz on IRC] 2002-01-28 09:03:34 PST
ccing David to look at the nsCSSFrameConstructor issues (And review the patch?)
Comment 17 User image karnaze (gone) 2002-01-28 09:32:15 PST
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 User image anthonyd 2002-02-05 14:34:22 PST
this patch got its 'r=', has it passed the regression tests?
Comment 19 User image Denis Antrushin 2002-02-06 04:14:37 PST
Where I can find those tests?
Comment 20 User image Kevin McCluskey (gone) 2002-02-06 15:31:17 PST
Marking nsbeta1+
Comment 21 User image Marc Attinasi 2002-02-11 12:40:53 PST
*** Bug 123490 has been marked as a duplicate of this bug. ***
Comment 22 User image Marc Attinasi 2002-02-11 12:44:33 PST
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 User image Marc Attinasi 2002-02-11 12:45:56 PST
Comment on attachment 66734 [details] [diff] [review]
propesed patch, v1

sr=attinasi
Comment 24 User image karnaze (gone) 2002-02-11 13:22:38 PST
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 User image karnaze (gone) 2002-02-12 08:04:34 PST
The patch is in. Thanks Denis!
Comment 26 User image Marc Attinasi 2002-02-12 10:38:39 PST
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 User image Bob Kanefsky 2002-02-13 23:09:11 PST
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

Note You need to log in before you can comment on or make changes to this bug.