304598 - Hang up loading this page

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Max Alekseyev]

Seamonkey/linux build 2005081310

Seamonkey hangs up while loading the provided page.

Comment 1

[Max Alekseyev]

Links browser loads the same page in a matter of seconds. So does Seamonkey if
the page is loaded from local disk. But loading this page from the Internet
makes Seamonley not responding to mouse/keyboard, so it has to be killed.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050813
Firefox/1.0+ ID:2005081312

That's true; 100 cpu usage.

Comment 3

[Hermann Schwab]

Attachment: reduced testcase #1

reduced number of directory entries (links) from 21430 to 7.

The file is 2471 kb sized, and doesn't validate, also if I remove the google
header infront of the original file.

Comment 4

[Hermann Schwab]

Attachment: reduced testcase #2

removed google header from testcase #1, and added  <base href=...

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<BASE HREF="http://free.hostdepartment.com/m/"><table border=1
width=100%><tr><td><table border=1 bgcolor=#ffffff cellpadding=10 cellspacing=0
width=100% color=#ffffff><tr><td><font face=arial,sans-serif color=black
size=-1>This is <b><font color=#0039b6>G</font> <font color=#c41200>o</font>
<font color=#f3c518>o</font> <font color=#0039b6>g</font> <font
color=#30a72f>l</font> <font color=#c41200>e</font></b>'s <a
href="http://www.google.com/help/features.html#cached"><font
color=blue>cache</font></a> of <A
HREF="http://free.hostdepartment.com/m/"><font
color=blue>http://free.hostdepartment.com/m/</font></a> as retrieved on 10 Aug
2005 01:30:09 GMT.<br>
<b><font color=#0039b6>G</font> <font color=#c41200>o</font> <font
color=#f3c518>o</font> <font color=#0039b6>g</font> <font
color=#30a72f>l</font> <font color=#c41200>e</font></b>'s cache is the snapshot
that we took of the page as we crawled the web.<br>
The page may have changed since that time.  Click here for the <A
HREF="http://free.hostdepartment.com/m/"><font color=blue>current
page</font></a> without highlighting.<br>
This cached page may reference images which are no longer available. Click here
for the <A
HREF="http://64.233.179.104/search?q=cache:J871grFeJ0MJ:free.hostdepartment.com/m/&hl=en&lr=&strip=1"><font
color=blue>cached text</font></a> only.<br>To link to or bookmark this page,
use the following url:
<code>http://www.google.com/search?q=cache:J871grFeJ0MJ:free.hostdepartment.com/m/</code></font><br><br><center><font
size=-2><i>Google is not affiliated with the authors of this page nor
responsible for its
content.</i></font></center></td></tr></table></td></tr></table>
<hr>

Comment 5

[Hermann Schwab]

testcase 1 gives 25 errors, testcase 2 only 9 errors, because <img> and <hr> are
not allowed inside a <pre> section. If I remove the <pre> tags, testcase 2
validates tentatively. I removed the <pre></pre> tags from a local copy of the
original file, google header also removed, and it still took a lot of time to
finish rendering.


http://validator.w3.org/check?uri=https%3A%2F%2Fbugzilla.mozilla.org%2Fattachment.cgi%3Fid%3D192665&charset=%28detect+automatically%29&doctype=Inline&ss=1&verbose=1
http://validator.w3.org/check?uri=https%3A%2F%2Fbugzilla.mozilla.org%2Fattachment.cgi%3Fid%3D192666&charset=%28detect+automatically%29&doctype=Inline&ss=1&verbose=1

Comment 6

[Hermann Schwab]

Attachment: local testcases

download and unzip. Testcases take their images from archive.mozilla.org.

304598-25k-v.html is a validating file having 25 000 links, all the same. 
304598-5k-v.html  is a validating file having  5 000 links, all the same. 

304598-25k-nv.html and 304598-5k-nv.html are the files above made
non-validating by including the <pre> tags and excluding the encoding
specification, as seen in the original.

If you want to make smaller/bigger testcases, there are packs of links
included, just copy and paste and add the frontend and the backend.

I don't get a hang, CPU takes only a long time to load, and even longer to
unload after closing a tab.

testcase #1 and testcase #2 were for demonstarting the file structure, not for
showing the hang.
The testcases in this attachment unzip to 553kb and 276o kb sized files,
showing the slow load and unload time.

Comment 7

[OstGote!]

WFM. The original URL loads in Seamonkey trunk build 2005081505 on WinXP for me.
Takes some time but no hang or freeze and finally completed. The both testcases
load in < 1s for me.

Comment 8

[Max Alekseyev]

Linux specific?

Here it takes about 10 minutes to load the original URL. During that time
Mozilla is inoperable: it does not react to mouse and keyboard, does not redraw
its windows etc.

Comment 9

[Hermann Schwab]

Attachment: testcase with 2500 links

reduced testcase #1 and #2 were misleading (fast), they were for demonstarting
the code. The local testcases are zipped files with 5000 and 25000 links.
This unzipped testcase has 2500 links.

the 25000 links testcase needs about 95 seconds to render, and closing the tab
lets the 333 MHz Celeron also stay at 95% CPU for 95 seconds.

Comment 10

[Boris Zbarsky [:bzbarsky]]

This has nothing to do with HTTP networking.  The problem is that the page has
all these images on it all of which are nonexistent.  That means that we have to
replace the image frames with alt text and doing this is slow (and more
importantly O(N^2) in page size).  Not sure why yet, but it doesn't make much
sense to look into it until bug 11011 is fixed.

Note that from local disk this is only fast because of bug 282432.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Profile of that page

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: Original page, zipped up in case it goes away

Comment 13

[Max Alekseyev]

(In reply to comment #10)
> The problem is that the page has
> all these images on it all of which are nonexistent.  That means that we have to
> replace the image frames with alt text and doing this is slow (and more
> importantly O(N^2) in page size).

Slow performance is only a half of the problem. The other half is that rendering
of the page blocks operability of the browser. I believe such blocking is much
serious problem when just slow rendering.

Comment 14

[Boris Zbarsky [:bzbarsky]]

It blocks because a single frame construction pass is non-interruptible and when
said pass takes O(N) time in the page size (as here) for a large page...

Comment 15

[Hermann Schwab]

(In reply to comment #10)
> This has nothing to do with HTTP networking.  The problem is that the page has
> all these images on it all of which are nonexistent.  That means that we have to
> replace the image frames with alt text and doing this is slow (and more
> importantly O(N^2) in page size). 

I always got the images, they exist. I made my testcases from this bug's URL:, 
replacing the folder images with images from   <BASE
HREF="http://archive.mozilla.org/">

on a Celeron 333 a local file with 25k links, images from mozilla URL above, needs:
with folder images about 90 seconds, without folder images about 47 seconds.
When I close the tab, it closes immediately, but CPU goes to 100% for a tab
with folder images about 75 seconds, without folder images about 10 seconds.

link with folder image:
<IMG SRC="/icons/folder.gif" ALT="[DIR]"> <A HREF="mnr/">mnr/</A>              
     26-May-2002 10:14      -  

link without folder image:
 <A HREF="mnr/">mnr/</A>                    26-May-2002 10:14      -  


links from the bug's URL(google cache):
<BASE HREF="http://free.hostdepartment.com/m/">
<IMG SRC="/icons/folder.gif" ALT="[DIR]"> <A HREF="Marciux/">Marciux/</A>      
         09-Jan-2003 05:45      -  

http://free.hostdepartment.com/m/icons/folder.gif doesn't exist, but I see the
folders, and got the code above, when I look at URL:

URL: is a google cache, the direct page still exists:
http://free.hostdepartment.com/m/
http://free.hostdepartment.com/icons/folder.gif



When the long page loads, you can follow the progres, see the scrollbar moving
when you scrolled down to the end, and the page is still loading. You see
something is going on while you wait.
The opposite takes place when you close the tab.
The page is gone immediately, one or two seconds later on a slow computer the
CPU load goes to about 100%  and stays at that level for up to the same time the
loading of the page took. As you don't see any progress, the page had gone long
ago, this seems to be a hang.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Why exactly did you change this to "ASSIGNED"?  It's not.

> replacing the folder images with images from <BASE
> HREF="http://archive.mozilla.org/">

Then you would no longer see the bug.

> The opposite takes place when you close the tab.

That's bug 304870, probably.

Comment 17

[Hermann Schwab]

(In reply to comment #16)
> Why exactly did you change this to "ASSIGNED"?  It's not.

Sorry, I don't know how I did change that to assigned, but I see that's been my
last comment. I've had memory problems, had to kill seamonkey as it didn't react
to closing, but was paging for minutes. Killing freed more than 200 MB.
 
> > replacing the folder images with images from <BASE
> > HREF="http://archive.mozilla.org/">
> 
> Then you would no longer see the bug.

I made the attachment 192671 [details] this way: 'local testcases'
I repeated one directory entry (folder image/link) 5k resp. 25k times and zipped
the result to shrink the file from megabytes to something I could attach.
The 25k version takes 5 times the time the 5 k version needs.

> > The opposite takes place when you close the tab.
> 
> That's bug 304870, probably.

Not probably, but exactly.

Comment 18

[Hermann Schwab]

had to make the bug invalid to remove the assignment, sorry for the bugspam.

Comment 19

[Boris Zbarsky [:bzbarsky]]

OK, other than bug 309107, which is an obvious bug, this is managing to hit a
few of the O(N^2) spots in layout:

1)  Recreating a frame involves calling ContentInserted, which looks for the
previous sibling frame.  Since the previous sibling _content_ is a nsTextNode,
this involves finding its primary frame, which is not hashed.  Which means a
linear walk on all the kids of our big block up to us, basically.  Repeated for
each image.  I've filed bug 309111 on this.

2)  Destroying the old frame involves nsBlockFrame::DoRemoveFrame, which is O(N)
in this case.

3)  Inserting the new frame puts us in nsLineBox::RFindLineContaining which ends
up with lots of calls to nsLineBox::IndexOf.

Not exactly sure what we can do about #2 and #3 offhand.

Comment 20

[Wayne Mery (:wsmwk)]

no longer hangs

Comment 21

[Boris Zbarsky [:bzbarsky]]

We stopped reframing in this case, since we now assume no image will ever load if it's not loaded by the time we construct the image frame.

Sadly, we might need to revisit this assumption in bug 455690, so marking dependent on that.

And we might want to file separate bugs on items 2 and 3 from comment 19...

Comment 22

[Marco Castelluccio [:marco]]

Is this a candidate for Snappy?

Comment 23

[Gregory Pappas [:gregp]]

These test cases seem to perform well now. Safe to close?

Comment 24

[Daniel Holbert [:dholbert]]

(In reply to Gregory Pappas [:gregp] from comment #23)

These test cases seem to perform well now.

Thanks -- I'll take your word for it, particularly given the time that's passed since this bug was last touched.

We can reopen (or track in new bugs with up-to-date info) if there's anything that needs further work here.

Closing as WFM given comment 23.