Huge RAM consumption and subsequent hang on Zalewski cgi tests

RESOLVED DUPLICATE of bug 141818

Status

()

defect
RESOLVED DUPLICATE of bug 141818
15 years ago
5 years ago

People

(Reporter: mozilla, Unassigned)

Tracking

({hang})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

Reporter

Description

15 years ago
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.
Reporter

Comment 1

15 years ago
Posted file testcase 1
Reporter

Comment 2

15 years ago
Posted file testcase 2

Updated

15 years ago
Blocks: Zalewski

Comment 3

15 years ago
Confirming freeze for both trunk and 1.7.x Mozilla builds (20041024).
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

15 years ago
BTW, my freezes are on Windows ME. Changing haddware/OS to All/All
OS: OS/2 → All
Hardware: PC → All

Comment 5

15 years ago
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

15 years ago
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

15 years ago
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.
Reporter

Comment 8

15 years ago
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.
Reporter

Comment 9

15 years ago
Argh, condesed -> condensed.

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

Comment 10

15 years ago
yep

*** This bug has been marked as a duplicate of 141818 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.