265846 - Huge RAM consumption and subsequent hang on Zalewski cgi tests

Status: RESOLVED DUPLICATE of bug 141818

(Core :: DOM: HTML Parser, defect)

Description

[Peter Weilbacher]

Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a5) Gecko/20041024

I will shortly attach two examples of garbled test pages created by the Zalewski
cgi test program. I am not sure what the common problem is, i just observe the
common result: when loading these pages, Mozilla starts consuming huge amounts
of RAM. On Linux, this takes 100% CPU for a short while and uses about 500 MB of
RAM after which I can continue browsing.

On OS/2 this is a real problem, because it basically hangs the machine with
(close to) 100% CPU usage. I can kill it with WatchCat and CPU usage drops
immediatly, but I have to wait 2 minutes or so until the process really ends.
Until then I cannot start any new programs, the error message tells me that no
more RAM is available. I therefore suspect that the problem here is that it
consumes all available shared RAM.

Marking OS/2 for now (may be a perf problem on other platforms) and because it's
created by these garbled test pages, select HTML parser as component not knowing
where else.

Comment 1

[Peter Weilbacher]

Attachment: testcase 1

Comment 2

[Peter Weilbacher]

Attachment: testcase 2

Comment 3

[Jacek Piskozub]

Confirming freeze for both trunk and 1.7.x Mozilla builds (20041024).

Comment 4

[Jacek Piskozub]

BTW, my freezes are on Windows ME. Changing haddware/OS to All/All

Comment 5

[Moiz Dohadwala]

Win2k sp4.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041025
MultiZilla/1.6.4.0b

most likely, it also corrupted compreg.dat. I could no longer download files by
clicking on them (bug #227439). I had to go to about:plugins to fix it.

Comment 6

[basic]

Attachment: testcase 1b (simpler version)

I've tried to simplify testcase 1 by:
1) putting the tags into lines,
2) then keep remove the first line until it does not use up all my RAM+swap,
3) check that line on its own to see if it uses all RAM+swap
4) repeat with second line ...
and came up with this.

Comment 7

[basic]

Attachment: testcase 2b (simpler version)

did similar stuff with testcase 2, but not as comprehensive. tried starting
with first 10 lines, then 20, .. and so on, until it show signs of filling
RAM/swap. Then subtracted the first 10 lines then 20 ... and so on. Then with
the remaining lines try to find the minimal lines by removing the lines between
the first and last lines that cause mem spike.

Comment 8

[Peter Weilbacher]

Attachment: Condensed testcase 2

Similarly, I condesed testcase 2 to this. I think both testcases have the large
rowspan and colspan numbers in common (at least Mozilla may interpret testcase
1b as having large numbers). Actually, both do not hang the browser forever.
Testcase 1b does display after using 421 MB, this new testcase 2b when using
1300 MB of RAM.

Comment 9

[Peter Weilbacher]

Argh, condesed -> condensed.

I think with these testcases this bug is just a dupe of bug 141818.

Comment 10

[basic]

yep

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