357777 - permanently 100% cpu usage (even with blank tab in safe mode)

Status: RESOLVED DUPLICATE of bug 357852

(Firefox :: General, defect)

Description

[Christian]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-GB; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-GB; rv:1.8.1) Gecko/20061010 Firefox/2.0

Since upgrading to version 2.0, Firefox uses all the cpu it can get, even when no page is displayed, even in safe mode. It is quite unresponsive, too. No idea how to track this down any further.


Reproducible: Always

Steps to Reproduce:
1. Open Firefox
2.
3.




I installed without deleting the old .app directory into /Applications/Browsers/.

Comment 1

[Andreas Grillenberger]

Try to create a new profile, I think your profile could be incompatible with 2.0
(http://kb.mozillazine.org/Profile_Manager#Creating_a_new_profile)

Comment 2

[Christian]

Yep, creating a new profile brings CPU usage back to normal. Even bug 357800 is solved by this.

But what does "incompatible with 2.0" exactly mean? Which parts of my old profile do I have to delete or change?

Comment 3

[Mats Palmgren (inactive)]

Christian, it would be very helpful if you could leave your original profile
intact for a little while and help us get to the bottom of the problem,
if possible.

In your home folder you should have a folder named something like this:
Library/Caches/Firefox/Profiles/XXXXXXXX.default/
in it you should have a file named XUL.mfasl
Please quit Firefox, then rename this file to ORIG-XUL.mfasl (don't delete)
and then start Firefox with the default profile - does the problem persist?

If Firefox does not offer you to choose a profile at startup, you can
run it from a Terminal command line like so:
/Applications.../firefox -profilemanager

If the problem persists, try the same procedure renaming the following file
Library/Application Support/Firefox/Profiles/XXXXXXXX.default/prefs.js
to ORIG-prefs.js  (the X's are some random characters)

Comment 4

[Christian]

Thank you for your hints, Mats. I was fiddling about yesterday evening with a copy of my profile (didn't know about the cache directory though). Apparently it's actually prefs.js and prefs-1.js that are responsible. I just tried to move aside XUL.mfasl with intact prefs*.js and the problem persisted.

Shall I send the two files to you (I have a bad feeling about just attaching them here publicly)?

Comment 5

[Christian]

*** Bug 357800 has been marked as a duplicate of this bug. ***

Comment 6

[Christian]

Please have a look at the description of bug 357800 if you didn't already. I marked it as a dublicate as I grew assured that the two problems not only appeared at the same time but also seem to have the same cause.

Comment 7

[Mats Palmgren (inactive)]

(In reply to comment #4)
> Shall I send the two files to you (I have a bad feeling about just attaching
> them here publicly)?

You could do that, but I'd even more appreciate if you could try to find
which line(s) of prefs.js is causing the problem.
The lines we're interested in begin with "user_pref"
Make a copy of prefs.js, then open it in a text editor, remove half of the
user_pref lines, restart Firefox, if the problem persists, remove some more
user_pref lines and so forth until you have a minimal prefs.js file that
reproduces the bug. (If the problem disappears at any point just "undo" the
latest edit and select some other lines for removal).

Comment 8

[Christian]

Ok, will do that. I just hope it's only one line per file. Gotta go to university now, will keep you informed when I find something.

Comment 9

[Christian]

Finally got the evil line:

user_pref("nglayout.debug.disable_xul_cache", true);

Removing it in both, prefs.js and prefs-1.js solves the problem. That was quite tricky to find out because for example you can remove that line, start FF (no problem), close it, reinsert the line, start FF (still no problem), close it, do nothing, reopen it... 100% CPU. Of course you didn't just delete this line in the first place and you didn't do nothing between closing and reopening FF so you will blame whatever you just did for the problem... Well, I finally got it and apparently you had quite a good guess with XUL already, Mats. Thanks for that for if you hadn't drawn my attention to this word I would still be deleting random lines and wondering why the same config produces different results.

Comment 10

[Mats Palmgren (inactive)]

Christian, thank you very much for tracking down the cause of the error.
It turns out it's already reported and being actively looked at.


*** This bug has been marked as a duplicate of 357852 ***