Site causes infinite loope that swallows all system memory

VERIFIED FIXED in mozilla0.9.9



18 years ago
17 years ago


(Reporter: mellow, Assigned: karnaze)


({hang, testcase})


Firefox Tracking Flags

(Not tracked)


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


(4 attachments)



18 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
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

18 years ago
Yup, hangs me, too.  Win98SE, 2002010403
Ever confirmed: true
Keywords: hang

Comment 2

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

Comment 3

18 years ago
I've found that

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

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

Comment 6

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

Comment 8

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


18 years ago
Keywords: testcase

Comment 9

18 years ago
Trying 'Layout' component as it seems to be related to CSS ( ).
It could also belong to 'Style System' ?
Assignee: asa → attinasi
Component: Browser-General → Layout
QA Contact: doronr → petersen

Comment 10

18 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 :

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

if(isset($arrCookie["css"]) && !isset($edit)) {
	header("Location: book.php");
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

book.php :
Set the cookie if given right parameters

if(isset($css) || isset($newsstring)) {
	$newsstring = str_replace(" ","",$newsstring);
	$arrCookie["css"] = $css; // so arrCookie !empty 1st time
	$arrCookie["newsstring"] = $newsstring; 


Comment 11

18 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; } :

Works fine - sorry.

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

Comment 13

18 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) {

Comment 14

18 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) {
(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) {
      if (nextInline) {

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

Comment 15

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

Comment 17

18 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

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

Comment 19

18 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

Comment 23

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

Attachment #66734 - Flags: superreview+

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.

Comment 25

17 years ago
The patch is in. Thanks Denis!
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
You need to log in before you can comment on or make changes to this bug.