Firefox spikes CPU to 100% while browser chrome stops working.




8 years ago
6 years ago


(Reporter: Matthew Waymost, Unassigned)


4.0 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [testday-20120413])


(7 attachments)



8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6) Gecko/20100101 Firefox/4.0b6
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6) Gecko/20100101 Firefox/4.0b6

When using Firefox, sometimes the browser will spike the CPU to 100% and the browser chrome ceases to function correctly (i.e. new tab button on the toolbar does nothing, buttons on websites have no effect, scrolling with trackpad doesn't work, etc.). After this occurs, when attempting to quit, the browser hangs. Only way to resolve is to force quit via Activity Monitor and restart.

I can't peg down a specific site or situation where this occurs; I can't reproduce it on demand. I also don't see anything logs in the Console.

This has occurred since Firefox 4.0b5.

Reproducible: Sometimes

Steps to Reproduce:
Unable to reproduce consistently.
Actual Results:  
Browser spikes the CPU to 100% and the browser chrome stops working.

Expected Results:  
Browser should operate normally.

Comment 1

7 years ago
I am running Firefox 4.0 (updated March 21) and consistently experience this problem.  I have been running it recently with a clean profile and have the same problem.  

I have sampled the process via the Activity Monitor and will include two saved reports.  (This is the version with the clean profile.)  

I don't know how to force quit and post the dump but will do that if I can figure out how.  

The problem gets incrementally worse the longer Firefox runs.  Currently it has been running for maybe three days and I can't use it at all.  Yesterday it was just balky.

Comment 2

7 years ago
Created attachment 524239 [details]
Process sample report from Activity Monitor (zipped text)

The vast majority of the CPU time is consumed by very deep stacks of anonymous function -- I suspect these are JITed JS code.  Typically these end with something very similar to:

26 InjectJaegerReturn
20 0x11a508646
20 xpc_LocalizeContext(JSContext*)
20 xpc_LocalizeContext(JSContext*)
20 NS_InvokeByIndex_P
20 mozilla::layers::ReadbackSink::~ReadbackSink()
20 mozilla::layers::ReadbackSink::~ReadbackSink()

Comment 3

7 years ago
Created attachment 530968 [details]
Zipped execution sample (OS X)

Had to zip attachment or it would be too large.  

This continues to happen if I let Firefox run for a couple of days.  I have about 90 tabs open but it happens with much fewer.  

After I quit and restart the memory drops a lot and the CPU is reasonable for a while.  This last time the memory dropped from 2.64 GB to 1.65 GB (where it has stayed).  CPU is about 50% (of course it jumps around).  

The pattern of execution is similar.  At the end of 505 calls of anonymous routines (for some reason, always 505 calls deep), I find the following -- calls to a few "real" routines:

22 0x12082b270
.22 InjectJaegerReturn
.  16 0x12611e8c6
.    16 xpc_LocalizeContext(JSContext*)
.      16 mozilla::layers::ReadbackSink::~ReadbackSink()
.        16 mozilla::layers::ReadbackSink::~ReadbackSink()
.          16 mozilla::layers::ReadbackSink::~ReadbackSink()
.            16 mozilla::layers::ReadbackSink::~ReadbackSink()
.              16 mozilla::layers::ReadbackSink::~ReadbackSink()
.                16 mozilla::layers::ReadbackSink::~ReadbackSink()
.                  11 mozilla::layers::ReadbackSink::~ReadbackSink()
.                  4 nsPrintSession::Release()
.                  1 nsXPTCStubBase::Stub249()
.  3 0x1249295b9
.    3 InjectJaegerReturn
.      3 InjectJaegerReturn
.        3 xpc_LocalizeContext(JSContext*)
.          3 xpc_LocalizeContext(JSContext*)
.            3 NS_InvokeByIndex_P
.              3 catch_exception_raise
.                2 PR_Lock
.                  2 __spin_lock
.                1 catch_exception_raise
.                  1 catch_exception_raise
.  1 0x11a7d51c7
.    1 InjectJaegerReturn
.      1 JSObject::clone(JSContext*, JSObject*, JSObject*)
.        1 js::JSProxyHandler::keys(JSContext*, JSObject*, js::AutoIdVector&)
.          1 JSWrapper::get(JSContext*, JSObject*, JSObject*, long, js::Value*)
.            1 JSObject::clone(JSContext*, JSObject*, JSObject*)
.              1 js_obj_defineGetter(JSContext*, unsigned int, js::Value*)
.                1 js_ReportErrorAgain(JSContext*, char const*, JSErrorReport*)
.                  1 JS_DHashTableOperate
.  1 0x124928f92
.    1 InjectJaegerReturn
.      1 InjectJaegerReturn
.        1 xpc_LocalizeContext(JSContext*)
.          1 xpc_LocalizeContext(JSContext*)
.            1 DumpJSValue
.              1 DumpJSValue
.                1 xpc_LocalizeContext(JSContext*)
.                  1 xpc_LocalizeContext(JSContext*)
.  1 0x12611e66e
.    1 xpc_LocalizeContext(JSContext*)
.      1 xpc_LocalizeContext(JSContext*)
.        1 NS_InvokeByIndex_P
.          1 mozilla::layers::ReadbackSink::~ReadbackSink()
.            1 mozilla::layers::ReadbackSink::~ReadbackSink()
.              1 0x10000bdfd
.                1 PR_Lock
.                  1 __spin_lock


7 years ago
Version: unspecified → 4.0 Branch
This bug was reported using a pre-release version of Firefox 4. Now that Firefox 4.0.1 final has been released, can you please update and retest your bug? A fresh profile would be a good starting place to test, If you continue to see the issue, can you please update this bug with your results?

Filter: firefox4prebugsunco

Comment 5

7 years ago
I've encountered these symptoms with the released 4.0 and 4.0.1  I didn't bother reporting more often because it seemed like spam.  

I keep my installation quite current.  I believe my last report (05-08) was from 4.0.1, since I'm running 4.0.1 and the app was last updated 05-01.  

I've also encountered a problem with some similar symptoms, but not 100% CPU -- instead very large real memory but low CPU.  In that case the hang is probably due to paging, but it is hard to be sure.  

I'll attach profiles.

Comment 6

7 years ago
Created attachment 537496 [details]
Zipped execution samples (OS X)

The sample from 06-04 is typical (hung with over 100% CPU).  The sample from 06-05 is different -- about 5.5 GB real memory, low CPU, but very much hung.  

Typical stats are about 1.5 GB, 50-60% CPU (since my machine has 8 cores this doesn't annoy me).  This can persist for days or weeks, and then fairly quickly "go bad".  Quitting and then restarting restores the app to usability, with the same tabs.

Comment 7

7 years ago
Created attachment 537909 [details]
sampled capture of firefox-bin

Seeing similar callstacks although with idle situations--no flash or java or anything (all disabled locally), and sometimes no window visible. Callstacks always rooted in JSD_DebuggerOnForUser and followed by insanely deep callstacks (JITed JS?). I had suspected something firebug related (javascript debugger) but the issue persists even after uninstalling it. See attached samples.

Comment 8

7 years ago
Meant to mention that my cpu load is a constant 2-15% when this is happening, not the spikiness from above, I've just been casting about based on the JSD_DebuggerOnForUser stack frame and found this bug.

Comment 9

7 years ago
At suggestion of some folks in #firefox on IRC I tested:

4.0.1: original reported behavior
4.0.1: with add-ons disabled: same
4.0.1: with add-ons and plugins disabled: same
5.0b with add-ons and plugins disabled: same

Comment 10

7 years ago
Created attachment 537986 [details]
samples from nightly build

Sorry to serially update the bug, but I figure more info is better than less. I pulled a copy of nightly from mercurial last night and built it and this behavior seems to be absent, I only see a 1-2% load when idle. The samples look completely different so I assume the JS VM/JIT event model has completely changed? Samples from nightly attached for comparison.

Comment 11

7 years ago
Created attachment 540106 [details]
samples of hung FF, 5.0b7

Sadly the same problem arises in FF 5.0

I launched last night, FF worked OK after waking from sleep this morning, but it was hung when I came back this afternoon.  

The first sample is with all the windows open, 104% CPU and 2.11 GB real memory.

The second sample is after I quit, all the windows closed (fairly quickly, after waiting about a minute), memory fell to about 1.76 GB.  CPU was still 100%

The third sample is a few minutes later, CPU fell to 0% with occasional spikes to 5%, memory was still 1.76 GB.  No paging or other disk activity.  23 threads.

Then I force quit, relaunched with the same windows and tabs, about 20% CPU and 1.13 GB memory after the startup reload.  26 threads.

Comment 12

7 years ago
Created attachment 540637 [details]
Samples of hung Aurora

I got the most recent version of Aurora yesterday morning but it exhibits the same symptoms after running for less than 48 hours.  I was suspicious yesterday evening because the memory size was growing and the CPU % had crept up from around 20% to maybe 38%.  But this afternoon it hung at 100% CPU.  It was not completely dead -- every so often it would process a user event.  I quit it and eventually it did shut down.  After it closed all its windows it continued to run at 100% CPU for a while before the CPU declined, ran at a very low level for a while, and finally it actually shut down.  

Discouraging.  I hoped this would be gone in Aurora.
cant reproduce on Firefox 11, 12b4,13 and 14

for support please ask question in
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Whiteboard: [testday-20120413]
You need to log in before you can comment on or make changes to this bug.