331292 - Loading page causes freeze, no Talkback, both WindowsXP & Linux

Status: RESOLVED FIXED

(Core :: Layout: Floats, defect)

Description

[Peter Newman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Visiting the linked URL causes firefox 1.0.5.1 to freeze, where 1.0.7 works fine (IE also works fine). Other pages on the site seem fine, have not seen any on site that cause this (site is generated CMS).

Occurs on multiple WinXP machines, one with no extensions. Also freezes when Firefox is loaded in safe mode.
Left to sit for period of time does not seem to recover.

Full CPU usage (at least on Linux machine).

Reproducible: Always

Steps to Reproduce:
1. Visit URL

Actual Results:  
Loading progress bar fills to about 50-70%, Firefox UI becomes unresponsive. It seems that in some cases, part of the layout is rendered.
On WinXP:
Is marked as Not Responding, then close button will prompt to forcibly close. After some seconds, UI closes, Firefox can be re-launched.
On Linux: 
kill PID; will close process.

Expected Results:  
Page should have rendered.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Regression between 1.8b2_2005061506 and 1.8b2_2005061606.

Comment 2

[Martijn Wargers (dead)]

It also freezes when javascript is turned off.
Bonsai link:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-15+06&maxdate=2005-06-16+06&cvsroot=%2Fcvsroot

Comment 3

[Martijn Wargers (dead)]

Attachment: testcase

It seems to happen because of the large amount of floats on the page.

Comment 4

[Martijn Wargers (dead)]

So considering the regression range, could this be a regression from bug 292295?

Comment 5

[Martijn Wargers (dead)]

The testcase has a different regression range. That regressed between 2004-11-24 and 2004-11-25, which means that's a regression from bug 209694.

Comment 6

[Diego]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060317 Firefox/1.6a1 from cvs

It seems there is a sort of recursive loop in the stack trace.

#0  0xb6859dcb in nsLineList_iterator::operator-> (this=0xbf933ad8) at nsLineBox.h:602
#1  0xb6862331 in nsBlockFrame::PrepareResizeReflow (this=0x897e100, aState=@0xbf933d40) at nsBlockFrame.cpp:1872
#2  0xb6860b31 in nsBlockFrame::Reflow (this=0x897e100, aPresContext=0x894b840, aMetrics=@0xbf934334, aReflowState=@0xbf934150, aStatus=@0xbf934128)
    at nsBlockFrame.cpp:883

Then the following 5 are repeated at least 120 times

#3  0xb6870703 in nsBlockReflowContext::ReflowBlock (this=0xbf9342f0, aSpace=@0x897e490, aApplyTopMargin=1, aPrevMargin=@0xbf934950, aClearance=30,
    aIsAdjacentWithTop=1, aComputedOffsets=@0x0, aFrameRS=@0xbf934150, aFrameReflowStatus=@0xbf934128) at nsBlockReflowContext.cpp:645
#4  0xb6865b78 in nsBlockFrame::ReflowBlockFrame (this=0x897de64, aState=@0xbf9348e0, aLine={mCurrent = 0x897e4f0, mListLink = 0x897dea0},
    aKeepReflowGoing=0xbf9345e4) at nsBlockFrame.cpp:3467
#5  0xb68642b0 in nsBlockFrame::ReflowLine (this=0x897de64, aState=@0xbf9348e0, aLine={mCurrent = 0x897e4f0, mListLink = 0x897dea0},
    aKeepReflowGoing=0xbf9345e4, aDamageDirtyArea=1) at nsBlockFrame.cpp:2606
#6  0xb686319e in nsBlockFrame::ReflowDirtyLines (this=0x897de64, aState=@0xbf9348e0, aTryPull=1) at nsBlockFrame.cpp:2258
#7  0xb68601f5 in nsBlockFrame::Reflow (this=0x897de64, aPresContext=0x894b840, aMetrics=@0xbf934ed4, aReflowState=@0xbf934cf0, aStatus=@0xbf934cc8)
    at nsBlockFrame.cpp:891

that is here we have them again...

#8  0xb6870703 in nsBlockReflowContext::ReflowBlock (this=0xbf934e90, aSpace=@0x897e490, aApplyTopMargin=0, aPrevMargin=@0xbf9354f0, aClearance=0,
    aIsAdjacentWithTop=1, aComputedOffsets=@0x0, aFrameRS=@0xbf934cf0, aFrameReflowStatus=@0xbf934cc8) at nsBlockReflowContext.cpp:645
#9  0xb6865b78 in nsBlockFrame::ReflowBlockFrame (this=0x897dd04, aState=@0xbf935480, aLine={mCurrent = 0x897e550, mListLink = 0x897dd40},
    aKeepReflowGoing=0xbf935184) at nsBlockFrame.cpp:3467
#10 0xb68642b0 in nsBlockFrame::ReflowLine (this=0x897dd04, aState=@0xbf935480, aLine={mCurrent = 0x897e550, mListLink = 0x897dd40},
    aKeepReflowGoing=0xbf935184, aDamageDirtyArea=1) at nsBlockFrame.cpp:2606
#11 0xb686319e in nsBlockFrame::ReflowDirtyLines (this=0x897dd04, aState=@0xbf935480, aTryPull=1) at nsBlockFrame.cpp:2258
#12 0xb68601f5 in nsBlockFrame::Reflow (this=0x897dd04, aPresContext=0x894b840, aMetrics=@0xbf935a74, aReflowState=@0xbf935890, aStatus=@0xbf935868)
    at nsBlockFrame.cpp:891

and so on, at least up to #675 where I got tired of checking

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That's because this page is a set of very deeply nested blocks.

Comment 8

[David Losada]

I have another page with similar behaviour:
http://prdownloads.sourceforge.net/vdrift/vdrift-2006-10-06-minimal.x86.package?download


Firefox uses 100% cpu, but from time to time (for about 2 seconds) it responds (the circle of points on the upper right corner starts to move), but it is unusable.
Environment: W2K SP2, 512 Mb Ram, Pentium 4 1,4 GHz.

Comment 9

[Jesse Ruderman]

Martijn's testcase still hangs (tested with today's Windows trunk build of Firefox).

Comment 10

[Mike Schroepfer]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a6pre) Gecko/20070613 Minefield/3.0a6pre

Still occurs for me on windows - can also confirm that IE7 renders this without difficulty.   Roc - maybe Karl could take a look?

Comment 11

[Eli Friedman]

See also bug 321322 (especially bug 321322 comment 9).

Comment 12

[Eli Friedman]

Fixed by the patch to bug 320378.

Comment 13

[Mats Palmgren (inactive)]

Crash test:
https://hg.mozilla.org/integration/mozilla-inbound/rev/045c314c045b

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/045c314c045b