Site causes infinite loope that swallows all system memory

VERIFIED FIXED in mozilla0.9.9

Status

()

--
critical
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: mellow, Assigned: karnaze)

Tracking

({hang, testcase})

Trunk
mozilla0.9.9
hang, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [awd:tbl][p3][r=], URL)

Attachments

(4 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
Yup, hangs me, too.  Win98SE, 2002010403
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang

Comment 2

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

Comment 3

17 years ago
I've found that 

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

also crashes Mozilla. It works fine in MSIE.
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

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

Comment 6

17 years ago
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.
Hardware: PC → All

Comment 7

17 years ago
Created attachment 63752 [details]
HTML page that crashes Mozilla (saved from http://www.mellow.dk/book/book.php?css=transparent via sniffer)

Comment 8

17 years ago
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 ?

Updated

17 years ago
Keywords: testcase

Comment 9

17 years ago
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' ?
Assignee: asa → attinasi
Component: Browser-General → Layout
QA Contact: doronr → petersen
(Reporter)

Comment 10

17 years ago
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



(Reporter)

Comment 11

17 years ago
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.


confirm hang using 2002012203 build on WINXP.
Reassigning to Karnaze
Assignee: attinasi → karnaze
Target Milestone: --- → mozilla0.9.9

Comment 13

17 years ago
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

17 years ago
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

17 years ago
Created attachment 66734 [details] [diff] [review]
propesed patch, v1

Don't insert the same frame twice
ccing David to look at the nsCSSFrameConstructor issues (And review the patch?)
Keywords: patch
(Assignee)

Comment 17

17 years ago
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)
Attachment #66734 - Flags: review+

Comment 18

17 years ago
this patch got its 'r=', has it passed the regression tests?
Whiteboard: [awd:tbl][p3][r=]

Comment 19

17 years ago
Where I can find those tests?
Marking nsbeta1+
Keywords: nsbeta1+

Comment 21

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

Comment 22

17 years ago
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

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

sr=attinasi
Attachment #66734 - Flags: superreview+
(Assignee)

Comment 24

17 years ago
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.
Status: NEW → ASSIGNED
(Assignee)

Comment 25

17 years ago
The patch is in. Thanks Denis!
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 26

17 years ago
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

17 years ago
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.