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]

Categories

(Thunderbird :: Account Manager, defect, minor)

All
macOS
defect
Not set
minor

Tracking

(Not tracked)

People

(Reporter: nico, Unassigned)

References

Details

(Keywords: perf, regression, Whiteboard: [needs shark profile])

Attachments

(2 files)

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.
Version: unspecified → Trunk
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/
Keywords: perf
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?
Flags: wanted-thunderbird3+
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 2.0.0.19 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.
Attached file Shared library info
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?
Depends on: 487274
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 :-)
Henrik: https://developer.mozilla.org/En/Profiling_JavaScript_with_Shark mostly talks about using Shark to profile specific bits of an app, which is not really what we want to do here.  However, as part of that, it has info on how to sample using Shark.  I'd suggest getting a sample while Tb is idle and chewing CPU and posting it here.
still see this on trunk or current beta?
Severity: normal → minor
Attached file Shared library info
The same with Thunderbird 3 Beta 4. Still >1% CPU consumption though no windows open (Mac OS X) and finished indexing.
Keywords: regression
Whiteboard: [needs shark profile]
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?
Flags: needinfo?(e.berberich)
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.
Flags: needinfo?(e.berberich)
You need to log in before you can comment on or make changes to this bug.