100% cpu usage, hangs on quit and simple kill, have to kill -9

RESOLVED INCOMPLETE

Status

()

--
critical
RESOLVED INCOMPLETE
8 years ago
4 years ago

People

(Reporter: vgabor, Unassigned)

Tracking

({hang})

4.0 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

On some rare occasions (it happened so far 2 times) firefox start using 100% of cpu. Both times there was only 2 tab open, 2 gmail tabs. First happened about 3-4 minutes after the firefox was started, the other one after the laptop was woken up from sleep. 

Both times the quit firefox hangs up, it closes the firefox window, but the process keeps running in the background still eating up 100% cpu. Simple kill pid does not work, have to kill with -9. 

Process sample of the second time (too big to paste): 
http://vgabor.com/firefox/100cpu_usage

Reproducible: Couldn't Reproduce


Actual Results:  
100% cpu usage

Expected Results:  
not 100% cpu usage

Comment 1

8 years ago
Works for me on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a1) Gecko/20110508 Firefox/6.0a1
(Reporter)

Comment 2

8 years ago
Did happened again a minutes ago, FF version Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

It happened when I clicked on the 'open new tab' in the toolbar. It did not open a new tab, but cleared out the urlbar of the current one (which was a google web search page), focus went to the urlbar and it was waiting for the typing of the url. With 100% cpu usage.

Comment 3

8 years ago
The cpu goes to 100% and it stays there or the percentage is dropping after the tabs are opened?
(Reporter)

Comment 4

8 years ago
cpu went 100% and kept there, no dropping. and no new tab were actually opened. the ff window was still kind of responsive, I could type into the urlbar, but it appeared about 1 letter / 5 sec speed. click on the closing window closed it, but the ff process kept eating 100% cpu without a window, and closing the ff process with a simple quit in the mac menubar did not work, I had to kill it.

Comment 5

8 years ago
Could you see if the issue occurs if using an empty testing profile? (Don't install any addons into it)
http://support.mozilla.com/kb/Basic+Troubleshooting#w_8-make-a-new-profile
(Reporter)

Comment 6

8 years ago
happened again, this time when I woke up my notebook from sleep the ff woke up with 100% cpu. yesterday evening when it went to sleep it wasn't 100%
process sample: http://vgabor.com/firefox/100cpu_usage2


Unfortunately I can not reproduce this 100% cpu usage on will, it happens at random times. Is there any tool or logging option (for mac) to run when/after it happens and collect more information?

Updated

8 years ago
Version: unspecified → 4.0 Branch

Comment 7

8 years ago
Reporter, do you have anything new to add about this issue?
We are experiencing a similar situation here. Randomly the CPU usage ramps up to 100% and I have no choice but to kill the browser by force.

As an add-on developers, we initially thought this was a bug in the add-on we are working on (even though the problem never happened on Firefox 3.6), but then it occurred in other Firefox instance running a different profile that doesn't have the add-on installed.

Our user agent:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

As an additional note, we've noticed that when the CPU usage goes out of control, some timers (instances of nsITimer) we have defined in our extension get triggered, even though they are set to be fired hours later, not minutes as it is currently happening.

It is very hard to reproduce the problem in a consistent way. We normally open the browser and keep it open while we do something else. We find out the problem is occurring because the laptop's fan speeds up, then we open the activity monitor and CPU usage is 100%

We are willing to provide further assistance that leads to the cause of this problem, as it certainly might affect our add-on users.

Comment 9

7 years ago
Does the issue still occurs in Firefox 5?
Yes it does, specially when there are 2 Firefox instances running with different profiles, but it also happens having a single instance running.

Comment 11

7 years ago
I have this problem too. It's not reproducible at will but it happens all the time. Especially after sleep but not only then. Started with Firefox 4 and still the same with Firefox 5. I've also tried Safe mode. Same issues.

I have a Unibody macbook, 5gb RAM, 2.4GHz Core2Duo.

Comment 12

7 years ago
Does the issue occurs on latest Firefox?
The issue is still present on Firefox 5.0.1. In fact it is occurring more frequently since I upgraded from Firefox 4. It used to happen a lot when 2 or more different profiles were running at the same time, but since I upgraded to 5.0.1, it is happening very often (5-6 times a day) even with a single profile opened.

Updated

7 years ago
Severity: normal → critical
Keywords: hang

Comment 14

7 years ago
Please try to reproduce the issue on the new Firefox 6, wich will be released today.
Thanks
Upgraded to Firefox 6 yesterday and the issue still persists. In some cases the browser freezes completely when I do cmd+T to open a new tab.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 16

7 years ago
I've both upgraded to Firefox 6 and Lion. Still the same issue. But not as common.

Comment 17

4 years ago
Still see this issue when using a current version started in safe mode?
Flags: needinfo?(vgabor)
Flags: needinfo?(juan)
Flags: needinfo?(besddimo)
Whiteboard: [closeme 2015-04-10]

Comment 18

4 years ago
Resolved per whiteboard
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(vgabor)
Flags: needinfo?(juan)
Flags: needinfo?(besddimo)
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2015-04-10]
You need to log in before you can comment on or make changes to this bug.