345255 - Too much CPU time when idle, until session is reopened

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Vincent Lefevre]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

After some time, Firefox constantly takes about 10% CPU time in average (according to "top"), even when it is iconized. It doesn't make the machine slow, but this problem still has an annoying consequence: it makes the machine very noisy, because every few seconds the fan is going at a full speed.

After closing the window and reopening the last session, the Firefox CPU usage is back to a reasonable value: about 0.3%.

Reproducible: Sometimes




There are a lot of open bugs concerning CPU usage problem, but a lot of them seem to be different, and here, it disappears after reopening the session (but not for a long time). I think that I've never had such a problem under Linux.

Comment 1

[Steve England [:stevee]]

Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!

Comment 2

[Vincent Lefevre]

Yes, I let the Firefox minimized for about an hour, and Firefox took 5% CPU time in average. Firefox was running for one or two days only. After several days, it can take more CPU time.

Comment 3

[Vincent Lefevre]

This is worse with Firefox 3. After some time, it was permanently taking 100% CPU (even when iconized). After quitting and restarting it (with the session restored), it takes about 11% CPU.

Comment 4

[Timothy Miller]

I definitely want to add my vote to this bug.  I have several tabs open, but as far as I can tell, there are no animated images, and there are certainly no flash apps, and no other plugins are active.  But Firefox (nightly build as of 2009-2-14) is using 5% CPU.  What is it polling on?  I read an article recently about some people who put a lot of work into switching Firefox over from polling to event-driven so as to reduce CPU usage.  Have these changes not made it into 3.1 beta?

And I'll also confirm that if some plugin (e.g. Flash, QuartzPDF) takes CPU time, and then you close the tab that used the plugin/extension, I would expect the CPU usage to go down, but it doesn't.

Even a completely empty session, where I restart the browser with no windows open, so Firefox is doing NOTHING, it still uses about 2% CPU.

Comment 5

[Tyler Downer [He/Him]]

does this happen in a New Profile in FF 3.0.7?

Comment 6

[Vincent Lefevre]

Attachment: Output of "sample <pid> 10 10"

I haven't tried a new profile, but the bug still occurs in FF 3.0.7. I've attached the output of "sample <pid> 10 10" (done while FF was iconized), in case this can be useful.

Comment 7

[Tyler Downer [He/Him]]

Can you reproduce in a new profile with 3.5.6 or later?

Comment 8

[Timothy Miller]

I stopped using Firefox several weeks ago because of the excessive CPU load (and the mac-no-sleep bug).  The last version I used was 3.5.4pre.  Is that recent enough?

I see the same pattern, BTW.  If I start out with an empty profile, FF uses a few % CPU.  As I open tabs, each one adds more load.  As I close them, the load doesn't go down to where it was when I started.

Comment 9

[Vincent Lefevre]

Firefox was constantly taking around 60 - 70% CPU time. I closed some tabs, leaving only 4 tabs from my web site (which I know they shouldn't be the cause of this problem), without any effect. The problem disappeared after I closed the window. It didn't reappear after reopening the session.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6

Comment 10

[Vincent Lefevre]

Occurred again. This new problem seems to be specific to FF 3.6.

Comment 11

[Vincent Lefevre]

And again, now 100% CPU time. Seems a reproducible problem with FF 3.6.

Comment 12

[Vincent Lefevre]

I've found that this problem with FF 3.6 is due to ClickCutter AutoCopy 1.2.1 (which I'm using instead of the old AutoCopy extension, which is not compatible with FF 3.6).

Comment 13

[Tyler Downer [He/Him]]

Please report to the authors of that extension then.

Comment 14

[Timothy Miller]

Extensions make the problem worse, and Firefox is partly responsible in that it doesn't seem to unload the extensions when not in use.  

But the problem nevertheless persists even when there are no extensions.  Opening tabs increases CPU usage, closing them does not reduce it.  This is like some kind of weird "CPU leak" where Firefox continues to poll on stuff that doesn't exist anymore.

Comment 15

[Tyler Downer [He/Him]]

Timothy, we aren't responsible for how extension authors code their addons. If an extension is causing the issue, then the developer of that addon needs to be notified. If the extension author finds that their addon is stumbling on a bug in firefox, then they can come raise a bug with us, but they know way more about that then a general user will because it is their software.
As for yours issue, it is different that the reporters because you say it still happens with no addons. If you see this is a fresh unmodified profile and firefox 3.6.8 or later, then please file a new bug.

Comment 16

[Vincent Lefevre]

Timothy, I also notice CPU leak (probably not due to the extensions), but concerning this bug report in particular, it is due to ClickCutter AutoCopy: the problem was (still is?) always reproducible on my machine after several dozens of seconds only (with ClickCutter AutoCopy as the only extension), even with a new profile and only one tab.

However Firefox could also be the cause: I reported the problem to the author, with the exact steps to reproduce it, but the author couldn't reproduce it and assumed it to be a bug in Firefox.

I eventually posted a message to a newsgroup (you can still see it):

  From: Vincent Lefevre <[e-mail]>
  Subject: Need testing under Mac OS X (ClickCutter AutoCopy)
  Newsgroups: mozilla.dev.extensions
  Message-ID: <20100215035748$[e-mail]>
  Date: Sun, 14 Feb 2010 22:21:24 -0600

hoping that someone else would test, thus helping to determine the cause of the problem, but there are still no replies. The community isn't very helpful to track bugs. :(