User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100914 Firefox/4.0b7pre Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100914 Firefox/4.0b7pre ID:00000000000000 At the abcnews.go.com/nightline, with javascript.options.methodjit.content enabled (the default), the browser causes 100 % CPU utilization and becomes completely unresponsive. The firefox.exe process has to be killed. No lockup if javascript.options.methodjit.content is disabled. Reproducible with the attached testcase (unreduced) M-C regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=16eac4b8b8e0&tochange=f1bd314e64ac TM regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8ce3a4a29efc&tochange=1b55ec0c7aee Strangely, the above is an empty pughlog, so I can't tell what changed. Reproducible: Always Steps to Reproduce: 1. Visit the linked URL or download and load the attachment. 2. Browser locks up with single-core 100 % CPU 3.

Confirmed in TM nightly. We appear to be ilooping in RemoveExcessFrames. This didn't happen in my local debug build, so it may have been fixed. Will have to check.

This bug still exists after the latest TM merge.

Today's TM merge still has the regression. Tested with cset: c3876f7bc3e8

We need to get the blocking nom here triaged. In particular, is this a b7 blocker?

Verified to be fixed by bug 597871.