25734 - Freezes, eats memory on very large/long page in M13

Status: VERIFIED DUPLICATE of bug 29641

(SeaMonkey :: General, defect, P3)

Description

[cdavison]

I found this bug in M13 (Build ID: 2000012520). My OS is Windows NT 4.0 SP4.

The Mozilla UI stops responding and Virtual Memory is exhausted very quickly
when a large page such as http://www.compaq.com/support/files/allfiles.html
(over 9MB in size) is loaded. The page loads fine in Netscape 4.x and (albeit
slowly) in IE 5.

I rebooted between attempts with each of the browsers to keep the memory
situation consistent. I have 128 MB of physical RAM and a 139 MB pagefile.

Comment 1

[Christian Mattar]

Marking perf

Comment 2

[leger]

Assigning all open "[e-mail]" bugs to "[e-mail]" to weed 
thru.

Comment 3

[Jeffrey Baker]

To quantify, this page loads in about three minutes and consumes 110 MB memory
on my Linux 2.2 i686 with a 750 MHz CPU and a fat pipe.

Comment 4

[chris hofmann]

real world example of the long file problems folks first noted with
tinderbox build logs.  It actually look like a substantial leak
might be going on here as well.  The pages appears to be about 9MBs
in size and not 110 MBs we seem to be sucking up when hitting the
page.

on win32 56k dialup I see a slightly different problem.  we start to load
the page and then just hang after about getting through about 20 sections
of this software patch report.

Comment 5

[chris hofmann]

assigned leger -> warren as a start to get this investigation going.

Comment 6

[Warren Harris]

Sounds like a dup of bug 25509 which is somewhat fixed, although bug 21637 is 
still there for additional improvements. 

cdavison: Can you verify that things are better with the latest build? Thanks.

Comment 7

[Phil Peterson]

PDT- for beta1. We should concentrate on getting memory use down after b1.

Comment 8

[cdavison]

The result was the same, or maybe even a little worse, with 2000020108. Here are
some numbers with W2k Pro:

M13 (2000012520): 85 MB used by mozilla, 3 min. to load page, another 2 min. to
close the window and exit
2000020108: 61 MB used by mozilla (climbed to 91, then down to 61), ~4 min. to
load page, another 2 min. to close the window and exit

I couldn't test the page with the 2000-02-02 build. I couldn't get past creating
a profile, something about a script error with one of the buttons. Yes, I did
delete c:\winnt\mozregistry.dat :)

Comment 9

[cdavison]

Additional things I forgot to mention: in both M13 and 2000020108, the console
said "2 webshells being leaked" before exit. As well, with both builds, the page
would NOT scroll past about 1/4 the total length until after the entire page had
been loaded (similar to the situation described in the comments for bug 21637).

Comment 10

[Warren Harris]

What kind of system do you have?
- processor speed
- physical memory
- virtual memory

Comment 11

[cdavison]

PIII-500, 4MBps DSL connection. My memory situation is as described above (128
MB physical, 139 MB swap).

I managed to get 2000020215 working today and it worked exactly the same as M13.

Comment 12

[Warren Harris]

This page takes 1 min 15 sec to load on my PII 466mhz machine. And it's very 
large. I'd say this is a low-probability case we can deal with after beta, 
although it definitely needs to get fixed long term. Since it is layout 
bounded, I'm passing it off to Vidur.

Comment 13

[jst]

I opened this with a nightly build (2000022108) on WinNT (PII, 400MHz, 256Mb)
and here's the performance output from that build:

Content creation time (this=01C9B1C0): Real time 0:0:18.534, CP time 19.718
Reflow time (this=01C524A0): Real time 0:0:25.34, CP time 23.874
Frame construction plus style resolution time (this=01C524A0):
        Real time 0:0:56.752, CP time 56.611
Style resolution time (this=01C524A0): Real time 0:0:34.437, CP time 33.839
Parse Time (this=01C9B530): Real time 0:0:24.57, CP time 24.525
DTD Time: Real time 0:0:27.497, CP time 26.598
Tokenize Time: Real time 0:0:5.193, CP time 5.157
Total (Layout + Page Load) Time (webshell=01C2E450):
        Real time 0:2:28.524, CP time 146.000

Given the file size (9Mb+) I'm positively surprised that mozilla handles this as
well as it does!

Comment 14

[vidur (gone)]

We're doing a lot better than when the bug was originally reported, but there's 
considerable room for improvement. This is very similar to 29641, which also has 
a lot of text interspersed with markup. Marking it a DUP - it should be used as 
an additional test case.

Troy, let me know if you think this should be considered separately.

*** This bug has been marked as a duplicate of 29641 ***

Comment 15

[Blake Ross]

*spam* changing qa contact from [e-mail] to me ([e-mail]) 
on 121 open or resolved (but not verified) bugs.  sorry for the spam everybody, 
but most of these bugs would just remain dormant and not checked by QA 
otherwise.  I'm not sure how so many bugs have nobody as their QA contact, but 
I suspect this is the fault of some sort of bugzilla corruption that happened 
at some point (most of these bugs are in the 20000-26000 range, and I don't see 
where in the activity log that QA contact explicitly changed to 
[e-mail])

Anyways, sorry again for spam.  If you really get annoyed, I'm usually 
available in #mozilla on IRC for torture.

Comment 16

[Matt Perry]

Verified duplicate.