TM: [Pentium 3] 100 % CPU utilization, rare run-away memory consumption [http://www
.fancast] .com/static-25168/js/bottom _combined .js
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091112 Minefield/3.7a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091112 Minefield/3.7a1pre ID:20091112045818 At the linked URL, Minefield experiences 100 % CPU utilization with JIT content, due to the script: http://www.fancast.com/static-25168/js/bottom_combined.js Disabling JIT content allows the page to load without issue. Reproducible: Always Steps to Reproduce: 1. Make sure JIT content is default 2. Load the linked URL 3. Notice the 100 % CPU utilization.
Created attachment 412048 [details] test case: web page archive. Loading this will also cause 100% CPU in the contained bottom_combined.js script.
The memory consumption aspect of this bug is difficult to reproduce.
Summary: TM: 100 % CPU utilization, occasional run-away memory consumption [http://www.fancast.com/static-25168/js/bottom_combined.js] → TM: 100 % CPU utilization, rare run-away memory consumption [http://www.fancast.com/static-25168/js/bottom_combined.js]
Regression Range: TraceMonkey: 1257362374-20091104111934-7d834c0884b7-firefox-3.7a1pre 04-Nov-2009 12:35 1257335057-20091104034417-24b4d2efe0b4-firefox-3.7a1pre 04-Nov-2009 05:16 Minefield Nightly: 1257403024-20091104223704-c9fe484ebc81-firefox-3.7a1pre 05-Nov-2009 00:20 1257392568-20091104194248-eb2a556deb11-firefox-3.7a1pre 04-Nov-2009 21:20
Version: unspecified → Trunk
In my STR, when I wrote, "Load the linked URL," the URL I was referring to is http://www.fancast.com/ NOT the script URL.
Whiteboard: SEE COMMENT #4
Severity: major → critical
Note: I'm on an Intel P3, so I wonder if there's an architecture-specific bug?
(In reply to comment #6) > Note: I'm on an Intel P3, so I wonder if there's an architecture-specific bug? I tried fancast.com with m-c nightlies of 11/1, 11/4, 11/5, and 11/12. On all of them, my average CPU usage was 13%. Most of the time it was 6%, but spiked to 50%+ every 4 seconds or so. This is on a 2.2GHz Core 2 of 2007 vintage. It is plausible to me that a P3 would have 100% CPU usage on the same load. For me, turning content JIT to false on this page had no effect on CPU usage. It may be architecture-specific; there were a few changes to the JIT backend on Nov 4. bug 516348 and bug 517405 look like the most likely to have had an effect.
Thanks David, I'm going to add blocking on those till somebody can take a look at this. The regression is pretty bad for my CPU.
Summary: TM: 100 % CPU utilization, rare run-away memory consumption [http://www.fancast.com/static-25168/js/bottom_combined.js] → TM: [Pentium 3] 100 % CPU utilization, rare run-away memory consumption [http://www.fancast.com/static-25168/js/bottom_combined.js]
Bug 516348 and bug 517405 seem unlikely to have caused this problem, IMO. You've narrowed the regression range down to six revisions, can you narrow it down to one?
(In reply to comment #9) > Bug 516348 and bug 517405 seem unlikely to have caused this problem, IMO. > You've narrowed the regression range down to six revisions, can you narrow it > down to one? How? I don't see any more frequent hourlies in the archive. Is there another hourly archive somewhere?
@Nicholas: By the way, if you look at the following TraceMonkey changelog for the regression interval: http://hg.mozilla.org/tracemonkey/log/f3e9ac90c086 you will notice that the only check-ins within the regression window are bug 516348 and bug 517405. It is impossible that any other check-ins are the issue. So unless I'm not understanding you, one of those check-ins caused the regression.
I don't know how the hourly archives work. According to 'hg log', in the tracemonkey repo we had the following commits between 7d834c0884b7 and 24b4d2efe0b4: changeset: 34381:7d834c0884b7 user: Graydon Hoare <firstname.lastname@example.org> date: Wed Nov 04 10:28:43 2009 -0800 summary: Update nanojit-import-rev stamp. changeset: 34380:f0d5ea88d07f user: Graydon Hoare <email@example.com> date: Wed Nov 04 10:15:41 2009 -0800 summary: Bug 526011 - Backed out changeset ccae3c736aed, premature landing. changeset: 34379:04014b568209 user: Nicholas Nethercote <firstname.lastname@example.org> date: Wed Nov 04 16:44:13 2009 +1100 summary: Bug 517405 - nanojit: don't compute x86 FP conditions twice(!). r= rreitmai. changeset: 34378:6b96e43a6dd3 user: Nicholas Nethercote <email@example.com> date: Wed Nov 04 14:45:29 2009 +1100 summary: Bug 516348 - nanojit: add findSpecificRegForUnallocated(). r=edwsm ith. changeset: 34377:34f7de7463c0 user: Graydon Hoare <firstname.lastname@example.org> date: Tue Nov 03 11:49:31 2009 -0800 summary: Bug 525392 - Fix ARM branch-patching logic, r=vlad. changeset: 34376:280561a45b76 user: Graydon Hoare <email@example.com> date: Mon Nov 02 17:10:27 2009 -0800 summary: Bug 526070 - lirasm call argument ordering bug, r=dvander. changeset: 34375:b64f119567bf user: David Anderson <firstname.lastname@example.org> date: Tue Nov 03 10:16:17 2009 -0800 summary: Removed Fragment::vmprivate and Fragment::root (bug 526011, r=grayd on). changeset: 34374:24b4d2efe0b4 user: Luke Wagner <email@example.com> date: Tue Nov 03 15:22:48 2009 -0800 summary: Bug 526356 - invalid debug memset of global native frame in Executr eTree (r=dvander) How did you determine the regression range?
(In reply to comment #12) > How did you determine the regression range? All I did was determine which hourly builds first included the regression, using the hourly archives here: http://hourly-archive.localgho.st/hourly-archive2/tracemonkey-win32/ http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/ As for your list: 1. 34381:7d834c0884b7 - This doesn't look like it is likely to have caused the regression, but I'm guessing. 2. 34380:f0d5ea88d07f - Doesn't seem likely. Builds following this supposed backout still exhibited the regression. However, I have been unable to determine where this relanded. 3. 34379:04014b568209 - Suspected 4. 34378:6b96e43a6dd3 - Suspected 5. 34377:34f7de7463c0 - Obviously, this should not affect x86 6. 34376:280561a45b76 - I guesss this is a possibility. 7. 34375:b64f119567bf - Same as #2. @Graydon: Is there anything in your changes that had the potential of causing this?
The regression-causing changes have not yet made their way into Namoroka, so I've removed the blocking request for now.
Patch #4 had a follow-up (34692:515d7e584de6) that fixed a problem with it. If you're using a non-debug build that might explain it. (If you're using a debug build the problem should have caused assertion failures.) Can you try an hourly build from after that follow-up and see if the problem is still present?
(In reply to comment #15) > Patch #4 had a follow-up (34692:515d7e584de6) that fixed a problem with it... > ...Can you try an hourly build from after that follow-up and see if the problem > is still present? That was it. So Bug 516348 was the cause. The following hourly TraceMonkey build contains the fix: 1258333637-20091115170717-30f8f6dcf808-firefox-3.7a1pre 15-Nov-2009 19:00 Now just gotta wait for it to land on mozilla-central before I can mark it fixed. Thanks
Excellent! The best kind of bugs are the ones I've already fixed :) Thanks for trying new version. Interesting that it caused 100% CPU utilisation, I wouldn't have expected that.
YEAH! Fixed by check-in for bug 527874 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091119 Minefield/3.7a1pre ID:20091119050202
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Great, thanks for the feedback.
Issue is resolved - clearing old keywords - qa-wanted clean-up
You need to log in before you can comment on or make changes to this bug.