146468 - Gigantic form with many inputs eats up all memory

Status: RESOLVED DUPLICATE of bug 148636

(Core :: Layout: Form Controls, defect, P2)

Description

[Filip]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; pl-PL; rv:1.0rc2)
Gecko/20020510
BuildID:    2002051006

bloat.html is 4,7MB big, is forms&tables only (some badly nested)

Its look like memory leaking problem because shorter versions displays correctly
(this one is database dump with ~2000 records)

Mozilla eats ram (1MB/s) up to 180MB (test machine is 4xPIII; 3,6GB RAM; RAID5
SCSI HDD; Win2K SERV) and quits when scrolling down.

Without doctype tag it renders that page (from local drive) 20 minutes, shows
misdrawings, and quits after scrolling page down.( rendering process eats up to
160MB and when finished it frees something staying at 120MB)

with doctype tag it renders page 'ad infinituum' mem usage is periodical: grows
until 180, then immediately drops to 90-120 and grows up to 180 and again. I was
watching this for 40 minutes and gave up.
griwing tempo is ~1MB/s

I was loading this page from local harddrive, I have uploaded it on
infralabs.com/~filip/mozilla for others.

Why I think it's a bug?
Well, I was positively dissapoited with IExploder, when it got that page "up and
running" in 1 minute (1m07s cpu time), eating up to 90MB and was freeing ram
down to 4MB when I stopped scrolling this up,down,left,right for few seconds and
it was ready for rumble scrolling again without noticeable delay, at once. 
IE survived flawlessly expanding&scrolling last wide combo  box which contains
~1000 entries(some of them very long and with nasty characters)

Tested this with 1.0RC2 with pl-PL lang pack added

feel free to bug me for any details
Filip

Reproducible: Always
Steps to Reproduce:
1.open http://infralabs.com/~filip/mozilla/bloat.html or attachment(if I managed
to add it)
2.scroll down while loading or after


Actual Results:  all loaded instaces of mozilla quit at once, no dr watson or VS
debugger  launched to intercept mem violation (looks like its no mem violation :)

Expected Results:  survive that, display page and allow expanding last vide
combo box with bunch of nasty long entries and tons of shorter ones

Comment 1

[Michael Gabriel]

hui, this was fun.
rendered happily and ate up 130+130 megs ram. i could still scroll around.
then i let it sit for a while, until it used 180+180 megs.
all mozilla windows started flickering, none did fully redraw, didnt respond,
100% cpu usage.
2002070504 trunk win2k

Comment 2

[Cees T.]

Related to bug 98835?

Comment 3

[rods (gone)]

-->

Comment 4

[John Keiser (jkeiser)]

OK, this form has 10,000 controls.  It takes a lot longer than IE and takes up
less memory.  Us taking a lot longer is probably due to a combination of
swappage and table reflows (this is one bigass table--karnaze, seen something
like this?).    Us taking up more memory might be due to problems with form
control bloat.

I did some independent testing and (if my stupid method of looking at how much
memory the program takes before about:blank and after viewing the page) 1,000
input type=texts with 11 characters each takes up 20M on Mozilla and 1M on IE. 
That's a huge difference.  Strange, though, that IE renders the page in this bug
with only half the memory instead of 1/20th.

Comment 5

[Carine Held]

Reproduced on 1/03/03 Trunk Win XP. Testcase keyword added.

Comment 6

[Andrew Schultz]

this seems like a dupe of bug 148636
for the table performance, see bug 148338 and bug 54542

Comment 7

[Marco Castelluccio [:marco]]

As the testcase is gone, marking as duplicate of bug 148636.