Open Bug 470001 Opened 11 years ago Updated 4 years ago
Thunderbird consumes very low CPU though being idle when no accounts are defined [Mac]
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20081217 Shredder/3.0b2pre When being idle (i.e. no mail is being sent or downloaded, or composed, etc., no window is open), Thunderbird still consumes some CPU. The OS X Activity Monitor displays between 1 and 5% of CPU for Thunderbird. Thunderbird 2.0 was at 0.0% with no windows open. TB3 should not waste CPU like this... Reproducible: Always Steps to Reproduce: 1. Open Thunderbird 2. Close all Thunderbird windows 3. Watch CPU consumption Actual Results: Thunderbird consumes between 1 and 5% of CPU. Expected Results: I would expect Thunderbird to consume NO CPU at all while not doing anything. No Add-ons are enabled.
Please try in Safe Mode. But I do not think that it will always be using no CPU when no activity is going on. It could be compacting in the background (and what do you mean "no window open"?), or doing other background, shuch as automatic checks.
Do you use IMAP account? If yes, check Syncing&Disk Space/Message Synchroniging setting. Is "Keep message for this account on this computer" enabled? If yes, which folders are chosen for automtic Syncing in "Advanced"?
This also applies to Shredder in Safe Mode with a new profile without any accounts. Then it's about 0.5% to 1% CPU - constantly (compacting or other background activities are ok, but not _all the time_).
(In reply to comment #1) > (and what do you mean "no window open"?) OS X allows an application to run without any window open. Start Shredder, close the main window, and it's still running (e.g. checking mail every # minutes).
Ok, thanks for the clarification. Can you answer the questions in comment 2 please.
(In reply to comment #2) > Do you use IMAP account? No, I have no account at all. Skipped the account creation. If I create a Gmail IMAP account, it's the same. > If yes, check Syncing&Disk Space/Message Synchroniging setting. > Is "Keep message for this account on this computer" enabled? No.
Nico, can you go back to some older trunk builds to determine when this behavior started - using binary search of older builds? ftp://ftp.mozilla.org/pub/thunderbird/nightly/
Summary: Thunderbird consumes CPU though being idle → Thunderbird consumes CPU though being idle and no accounts
Same here with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081206 Shredder/3.0b2pre ID:20081206031459 Running a system trace with Shark gives following callstac for the heaviest path: > 0.0 ns 114.5 ms thunderbird-bin start > 0.0 ns 94.8 ms thunderbird-bin start > 0.0 ns 85.9 ms thunderbird-bin start > 0.0 ns 85.9 ms thunderbird-bin XRE_main > 0.0 ns 82.1 ms XUL 0x16227e7 [unknown] > 0.0 ns 82.1 ms XUL 0x1780a8a [unknown] > 0.0 ns 82.1 ms AppKit -[NSApplication run] > 0.0 ns 82.1 ms AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] > 0.0 ns 82.1 ms AppKit _DPSNextEvent > 0.0 ns 82.1 ms HIToolbox BlockUntilNextEventMatchingListInMode > 0.0 ns 82.1 ms HIToolbox ReceiveNextEventCommon > 0.0 ns 82.1 ms HIToolbox RunCurrentEventLoopInMode > 0.0 ns 82.1 ms CoreFoundation CFRunLoopRunInMode > 0.0 ns 82.1 ms CoreFoundation CFRunLoopRunSpecific > 0.0 ns 49.1 ms XUL 0x17812da [unknown] > 0.0 ns 49.1 ms XUL 0x17b4710 [136B] > 0.0 ns 49.1 ms XUL JNIEnv_::CallStaticObjectMethod(_jclass*, _jmethodID*, ...) > 0.0 ns 49.1 ms XUL NS_GetComponentRegistrar_P > 0.0 ns 43.3 ms XUL 0x1780690 [369B] > 0.0 ns 33.8 ms XUL 0x17b4bdc [unknown] > 0.0 ns 33.8 ms XUL 0x17b47e0 [57B] > 0.0 ns 33.8 ms XUL 0x1780ae0 [1.1KB] > 0.0 ns 30.1 ms AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] > 0.0 ns 30.1 ms AppKit _DPSNextEvent > 0.0 ns 30.1 ms HIToolbox BlockUntilNextEventMatchingListInMode > 0.0 ns 30.1 ms HIToolbox ReceiveNextEventCommon > 0.0 ns 30.1 ms HIToolbox RunCurrentEventLoopInMode > 0.0 ns 30.1 ms CoreFoundation CFRunLoopRunInMode > 0.0 ns 30.1 ms CoreFoundation CFRunLoopRunSpecific > 0.0 ns 28.6 ms libSystem.B.dylib mach_msg > 28.6 ms 28.6 ms Unknown Library mach_msg_trap Do we spent the time in the event loop?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PowerPC → All
I've seen this too. Josh, is this just a cost of the way the Cocoa event loop code is implemented that we can't get away from? If not, any other ideas of stuff that might be causing this?
Maybe. Cc'ing smichaud. JNIEnv_::CallStaticObjectMethod This looks suspicious.
> JNIEnv_::CallStaticObjectMethod If the Shark trace is accurate (which it may not be), this indicates Java is running. But I don't see how this can be. As far as I know, Thunderbird/Shredder can't use Java. And in any case the JEP isn't bundled with it. I think this just means the Shark trace contains at least some spurious symbols.
Bogus symbols is always a good bet, but I'm reasonably sure (based on tinderbox logs) that we do in fact build-n-bundle the JEP (and probably have since bug 305098), and while in theory mailnews.message_display.allow.plugins keeps messages from loading plugins (unless Henrik has enabled it), the way plugins seem to load at the oddest times (like, while loading an RSS feed in Fx) makes me leery about saying absolutely that no plugin, including the JEP, would ever be loaded in Thunderbird.
Just a short note on Phil's comment: mailnews.message_display.allow.plugins is set to false.
> but I'm reasonably sure (based on tinderbox logs) that we do in fact > build-n-bundle the JEP (and probably have since bug 305098), Thunderbird 18.104.22.168 doesn't even have a Contents/MacOS/plugins directory. And in any case it doesn't bundle the JEP. But, to my surprise, I found out that a recent comm-central build (1.9.1-branch) does bundle the JEP. I don't know what the story is on the 1.9.0 branch. So I suppose it *is* possible that the Shark trace is accurate ... though (from what Henrik says) Shredder's default is not to allow plugins. The next step, of course, is to find out *why* Java is running ... if it really is running :-)
Sorry, one version of my comment did include "on trunk (on 1.8 we built with |MOZ_PLUGINS=| because old versions of Java would crash us on Linux while opening a message with an attachment with an unknown content type, even with plugins preffed off)" but I edited down. The story on 1.9.0 is there is no story: Tb2 is 1.8.1, Tb3.0 will be 1.9.1, Tb3.1pre is 1.9.2, and 1.9.0 is just the abandoned CVS trunk from before July 2008 when we moved the trunk to hg.
Here's an easy to tell whether or not Java (and the JEP) is really running in an instance of Shredder. This will work even with a distro that's had its debug symbols stripped. 1) Run Shredder in gdb. 2) Break in gdb and do 'info sharedlibrary'. Look for 'JavaEmbeddingPlugin' and lots of '*.jnilib' (among other things) in the list of loaded modules.
Shouldn't it be listed under the plugins tab of the add-ons manager then? I don't have a debug build so I cannot do the above mentioned steps but the plugin is not listed beneath Flip4Mac, Flash, Quicktime, and Silverlight.
> Shouldn't it be listed under the plugins tab of the add-ons manager > then? Yes, I suppose it should. But to really get to the bottom of this, we need gdb (or its equivalent). If you can't run Shredder in gdb, you can run Shredder first and then attach gdb to its process. This works with any build (and any program). 1) Run Shredder. 2) Do 'ps ax | grep thunderbird' at a Terminal prompt to find its process id. 3) Do 'gdb [pid] thunderbird' to attach to the Shredder process. 4) Do 'info sharedlibrary' in gdb. Look for 'JavaEmbeddingPlugin' and lots of '*.jnilib' (among other things) in the list of loaded modules.
I don't get any info because the state has not been initialized: (gdb) info sharedlibrary The DYLD shared library state has not yet been initialized. Requested State Current State Num Basename Type Address Reason | | Source | | | | | | | | I used the process analyzer now (somewhy shark auto-closes during start-up) and don't see this JNIEnv entry anymore. But the cpu load still goes up and down 0 - 1%.
Can you get Shark (or something else besides gdb) to list the loaded modules?
> I don't get any info because the state has not been initialized: Is Shredder running at this point?
And are you sure you have the right process id? :-)
(Following up comment #18) I just realized that step 3 is incorrect (the order of the parameters is reversed). Sorry for the confusion! Here are the steps over again, with step 3 corrected: 1) Run Shredder. 2) Do 'ps ax | grep thunderbird' at a Terminal prompt to find its process id. The pid will be listed in the first column to the left. Let's assume it's '123'. 3) Do 'gdb thunderbird 123' to attach to the Shredder process. 4) Do 'info sharedlibrary' in gdb. Look for 'JavaEmbeddingPlugin' and lots of '*.jnilib' (among other things) in the list of loaded modules. Henrik, please try these new steps. I strongly suspect my comment #11 was right, and that at least some of the symbols from comment #8 are spurious. But only gdb can really settle this issue.
Steven, those steps look better! But as you can see in the shared library info no Java library is loaded.
Thanks for the test, Henrik. I think its results rule out any role for Java (or the JEP) in this bug.
So what could I do in the next step to get some light into this mystic cpu cycles?
Henrik: a good next step would be to take a look at the build gozer has linked to in bug 487274 with Shark and comment in that bug about whether it provides better information than the regular builds. If so, pasting that info here would be a good plan.
Is there a page which provides more info how I have to handle such a build to get the wanted information? I haven't done that before and probably need some help.
Josh, Steven, do you guys have any thoughts on what would be most useful for Henrik to look for here?
Not beyond what's already been mentioned. But the most important thing (to re-emphasize) is to make sure that, whatever your source of information, you're not dealing with spurious symbols :-)
still see this on trunk or current beta?
Severity: normal → minor
The same with Thunderbird 3 Beta 4. Still >1% CPU consumption though no windows open (Mac OS X) and finished indexing.
I have basically the same problem, using Gentoo. When not running Thunderbird the total CPU load is around 2%, but as soon as I start Thunderbird the CPU load rise to between 15% and 50% for as long as Thunderbird is started, even though it's suppose to be idle. The weird thing is that the circular load indicator, or whatever it is, in the right top corner is constantly moving. So my guess is that it is not idle, but I can't figure it out what it's up to. I've deactivated all automatic updating and it's not sending nor retrieving mails. This is the case on my x86 laptop, but not on my amd64 desktop. Other than the difference in software due to different CPU architecture, the systems are more or less the same.
Are we at the point of needing something *other* than a shark profile? Robin, low cpu might be this bug. But higher cpu is some other issue - perhaps a bug, perhaps not :) "circular load indicator" = throbber
Summary: Thunderbird consumes CPU though being idle and no accounts → Thunderbird consumes very low CPU though being idle and no accounts [Mac]
Robin, Nico, etc, do you see this when using version 3.1, or trunk build?
Nico no longer uses thunderbird. Henrik and dmose are all it :)
We have about 0.2% of cpu load most of the time with some short spikes to 1.7% in intervals under 30s. So I would say it's still valid given the summary.
(In reply to comment #39) > We have about 0.2% of cpu load most of the time with some short spikes to 1.7% > in intervals under 30s. So I would say it's still valid given the summary. I see something very similar with Firefox (even though all its pages are idle), are you sure you're not seeing the same there?
I do, but I'm not sure which back-end processes are getting executed in both cases. So it could be the same. Someone should do create shark profile as mentioned earlier.
If this doesn't affect the case where we DO have accounts (do we know if it does?) do we even really care? If it is a regression from v2, there must be some obvious items to test. Gloda?
Component: General → Account Manager
QA Contact: general → account-manager
Eckard, can you reproduce this?
Summary: Thunderbird consumes very low CPU though being idle and no accounts [Mac] → Thunderbird consumes very low CPU though being idle when no accounts are defined [Mac]
Thunderbird 45 being idle in a new profile without any accounts consumes 0 or 0.1% CPU most of the time with occasional spikes (once every 5 min) of 1% CPU.
You need to log in before you can comment on or make changes to this bug.