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.

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

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

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.

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.

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.

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.

Argh, condesed -> condensed. I think with these testcases this bug is just a dupe of bug 141818.

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