168638 - Mozilla appears to go into an infinite loop rendering this page

Status: VERIFIED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Neil Booth]

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1) Gecko/20020826

Incremental reflow displays most of the page, and then CPU usage goes to 100%
and stays there for minutes (for me at least).  I got bored and killed it, and
reproduced the same issue.

Reproducible: Always

Steps to Reproduce:
1. Goto the specified URL.
2.
3.

Actual Results:  
Infinite loop (I think).

Expected Results:  
Shown the page.

Comment 1

[Mats Palmgren (inactive)]

For me it completes in about 7 minutes, using Opera it takes about 3.5 minutes.
Downloading the page using 'wget' takes about 3.5 minutes.
The page is ~10MByte big and the server seems to be a bit slow generating it.
Looking at the URL my guess is that it's fetching the data from a database and
it's there that the bottleneck is.
(I have a 10Mbit/s connection).

But you're right, Mozilla seems to steal an awful lot of CPU while it is
doing this page. It seems to do this only in periods though.
I have measured this (using 'top' so the numbers are approximate):
min:sec
0:00 - 1:02 => 3%  - 30% CPU (average about 15% CPU)
1:02 - 2:07 => 94% - 95% CPU
2:07 - 4:27 => 5%  - 35% CPU (average about 20% CPU)
4:27 - 7:00 => 93% - 94% CPU 
7:00 page finished.

I repeated the measurements three times with almost identical results.
2002-09-13-10 trunk Linux on a 733MHz PIII w. 256MB RAM

Comment 2

[Jean-Pierre Melkonian]

I Have the same problem With MaOS 9.1.
The page is to big for me.
I had CPU Overload, Permanent Pagination.
Finally i have rebooted

It is not the first time i have a problem with big pages
It is easy to reproduce that with a query on bugzilla

I suggest a maxPageSize setting in the prefs

Comment 3

[Andrew Schultz]

FWIW, some Jprof results.
Count %Total  Function Name
3092  15.1     nsLineLayout::FindNextText(nsIPresContext*, nsIFrame*)
1447   7.0     nsInlineFrame::ReflowInlineFrame(nsIPresContext*,
nsHTMLReflowState const&, nsInlineFrame::InlineReflowState&, nsIFrame*, unsigned&)
1366   6.7     nsContainerFrame::FirstChild(nsIPresContext*, nsIAtom*,
nsIFrame**) const
1342   6.5     nsFrameList::PullFrame(nsIFrame*, nsIFrame*, nsFrameList&)

the page is basically a table with 2 cells that are huge.
see also bug 56854...  A 10MB file is large!

memory usage was ok for me loading off disk.  used ~90 MB when it was one loading.

Comment 4

[Markus Hübner]

Think bug 94587 is related to this.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

attaching to the page layout perf bug and large page bug

This is a classic example of the "large flat pages are slow to load in mozilla";
there are O(n^2) and O(n log n) problems in handling of flat pages (or flat
table cells).

Attinasi isn't a good owner; reassigning to dbaron for now.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

From a fresh run on a dual-2GHz Linux box; recent trunk build.

Direct hits (args removed for ease of reading):

Total hit count: 11819
Count %Total  Function Name
3154   26.7     nsInlineFrame::ReflowInlineFrame()
2762   23.4     NS_NewFrameTraversal()
1411   11.9     nsLineLayout::FindNextText()
633   5.4     nsContainerFrame::Destroy()
297   2.5     nsInlineFrame::Reflow()
244   2.1     nsLineLayout::ForgetWordFrame()
199   1.7     nsVoidArray::InsertElementsAt()
179   1.5     nsSplittableFrame::SetPrevInFlow()
132   1.1     nsAutoString::~nsAutoString()
112   0.9     nsLineLayout::RelativePositionFrames()
 94   0.8     nsVoidArray::ReplaceElementAt()
 69   0.6     nsLineLayout::ReflowFrame()

nsInlineFrame::ReflowinlineFrame() calls NS_NewFrameTraversal(), so the total
for that is 50%(!)

nsTextFrame::MeasureText() adds up to about 35%(!) including children, 2/3rd of
which is nsLineLayout::FindNextText() (which hits most of the voidarray calls
above).

nsHTMLReflowState::nsHTMLReflowState() is around 3% including children.
SetFontFromStyle is around 2.5%

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

The main big-flat-page (or cell) bug is bug 72885

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Oops, I meant bug 67756

Comment 9

[Markus Hübner]

Can we try this with a recent build?

Comment 10

[R.K.Aa.]

with a current CVS build, Linux, I see no problem at the page at all.
Low CPU, nothing unusual. WFM

Comment 11

[Markus Hübner]

The URL in this bug also WFM using latest win32 trunk build.
Marking WFM

[ related to this seems bug 145425 ]

Comment 12

[Zibi Braniecki [:zbraniecki][:gandalf]]

verified on Linux nightly Fx