= Steps = 1. Go to http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1262649803.1262657487.23267.gz&fulltext=1 2. It will load for a long time and get to about 98% there (judging from the scrollbar and the little tab throbber) then it will stall Minefield and it will take 80-99% of the available CPU and spin. This happens on both Namoroka and Minefield: * Namoroka (clean profile): Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b6pre) Gecko/20091229 Namoroka/3.6b6pre * Minefield (old profile): Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091229 Minefield/3.7a1pre I also tried enabling the HTML5 parser in hopes that it might change the behavior. With HTML 5 enabled on Minefield, the page renders much faster (wall clock time is about a minute - minute and a half with HTML5.enable==false and about 30s with HTML5==true) but it still hangs and never completely finishes loading. By comparison, Safari (Version 4.0.3 (6531.9)) loads the same tinderbox log in about 25-30 seconds. I think that whatever we are doing at the end of the page load is causing contention and severely impacting the performance of Minefield which then in turn drags the entire computer's performance down with it. I opened three build logs in Minefield and my computer's responsiveness got so bad that I just rebooted the thing before I was able to determine what was causing it. This might be a dupe -- seems like it ought to be, but I couldn't find one. I'm not sure if this is parsing related or DOM generation related. The entire page never seems to load, but we do seem to have completed the network traffic, not sure if that helps. It's too late to take this on 1.9.2, but we should really take this on 1.9.3. I'm running a 13inch macbook: 10.6.2, 2.4 Ghz Core 2 Duo, 4 Gb of RAM and the only applications open are: Minefield (15 tabs), Namoroka, Thunderbird, Terminal, Colloquy, and Things. If this is going to be a long standing bug or something we decide to not block on this (which I would oppose) then we need to file a follow-on bug to have a better way to view tinderbox try server log files. That could be a small Automation & Infrastructure project.

I can verify that on trunk Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20100105 Minefield/3.7a1pre (.NET CLR 3.5.30729): While the log loads, trunk uses more and more RAM. At the same time, the CPU load rises until ~70 %. During that, one time it starts to hang, but can get responsive again. Continuing to attempt to load this page results in a even higher RAM load.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20100105 Minefield/3.7a1pre I notice the CPU and RAM usage slowly start to climb. It peaks around test #40000 with CPU usage at 70% and RAM usage nearing 1GB. I see this behaviour until I get well passed the #100000th test. The page eventually completes loading test #133458, CPU and RAM usage returning to normal. I'm on a Lenovo Thinkpad T61 (2.4GHz Centrino dual core, 4GB RAM).

Also happens on 3.5.6. I'm on a Lenovo TP W500 (Intel Core2 Duo T9600 @ 2.8 GHz and 4gb ram) Windows 7 64bit.

This one: Bug 519743 ?

Could be some test dumping RTL text into output and the enormous <pre> all getting bidi treatment. (I recall seeing bidi code on the stack when I poked at a slow tinderbox load.)

Jonas says he'll Shark this one.

Seems like this is a dupe of bug 477495. Duping, and nominating the duped bug for 2.0.