Yep - noticed myself - here is just cutoff from strace:

recvmsg(4, 0x7ffee42d1c20, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, 0x7ffee42d1c20, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
writev(4, [{"\24\0\6\0ZA\241\0J\1\0\0\6\0\0\0\0\0\0\0\4\0\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=4, events=POLLIN}], 1, -1)    = 1 ([{fd=4, revents=POLLIN}])
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0@\261\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(4, 0x7ffee42d1c20, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, 0x7ffee42d1c20, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
writev(4, [{"\24\0\6\0\257V\240\0J\1\0\0\6\0\0\0\0\0\0\0\4\0\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=4, events=POLLIN}], 1, -1)    = 1 ([{fd=4, revents=POLLIN}])
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0A\261\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(4, 0x7ffee42d1c20, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, 0x7ffee42d1c20, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
writev(4, [{"\24\0\6\0\260j\244\0J\1\0\0\6\0\0\0\0\0\0\0\4\0\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=4, events=POLLIN}], 1, -1)    = 1 ([{fd=4, revents=POLLIN}])
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0B\261\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(4, 0x7ffee42d1c20, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(4, 0x7ffee42d1c20, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
writev(4, [{"\24\0\6\0\221\0\240\0J\1\0\0\6\0\0\0\0\0\0\0\4\0\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=4, events=POLLIN}], 1, -1)    = 1 ([{fd=4, revents=POLLIN}])
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0C\261\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32

First of all be sure you have thunderbird-debuginfo installed:
debuginfo-install thunderbird
And then please try to gather some profiling data by perf:
sudo perf record -g -p `pidof thunderbird` -o thunderbird.data sleep 20
and after that:
sudo perf report -s dso -i thunderbird.data
and browse the report of most cpu hungry calls.

The top end of the "perf report" output page looks like so:

Samples: 75K of event 'cycles:ppp', Event count (approx.): 61534849337
  Children      Self  Shared Object
+   74.07%     0.00%  [unknown]
+   68.42%    63.43%  libxul.so
+   13.62%    13.00%  thunderbird
+    6.58%     6.58%  [kernel.kallsyms]
+    6.01%     5.57%  libglib-2.0.so.0.4600.2
+    5.77%     4.08%  libpthread-2.22.so
+    4.99%     3.86%  libc-2.22.so

(but this looks like modules running at sample time to me, not calls?)

(now on tbird 45.1.1 ...  dnf shows libxul.so being possibly provided
by all sorts of packages, including thunderbird - either I asked the
wrong question (dnf provides */libxul.so) or I don't understand the
concepts of modularity and dependencies.  "top" is showing tbird at
75% + continuously; occasional bursts to 400% (laptop has 4 cores)

The libxul.so is from Thunderbird. We cannot share libxul library with Firefox for example because of technical reasons. 

What I meant by 'browse' is that you should use arrows and enter keys to open libxul.so and look for the most frequent called methods from it. Sorry for not mentioning that before. Could you please post that detailed view or the .data file itself?

Created attachment 1178291 [details]
perf capture

Possibly associated with a relatively large number of new mails dealt with
(imap access; filters run and distribute to folders) in one chunk (laptop
boot-and-login the morning after a day off work).

Issue still present:
Thunderbird 45.2.0

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Seen again on f24, thunderbird 45.4.0

I'm also seeing this on RHEL7 with Thunderbird 52.0.1 and 52.2.1.

Is anyone still looking at this?

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Still present with 52.2.1 on f25   (4.11.10-200.fc25.x86_64).

I get the same problem with thunderbird 52.2.1 on f25 but this thing occurs for a very few moment (one-two days) 

after 10mn thunderbird takes 100% on one core of my processor. If I close it, it take a relative long time to stop and I get a mozilla bug report dialog after some times.

Comes from a bad plugins fixed for me

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Still occurs with thunderbird 52.4.0 on f27.

No better with Thunderbird 52.6/Lightning 5.4.6 on F27.

Still present with 52.7.0

Jeremy,
Does it happen with add-ons disabled, i.e. Thunderbird in safe mode?
With View > Toolbars > status bar disabled?

(In reply to Wayne Mery (:wsmwk) from comment #19)
> Does it happen with add-ons disabled, i.e. Thunderbird in safe mode?
> With View > Toolbars > status bar disabled?

That may be difficult to find out, since a restart always seems to clear the
issue.  I really don't want to run without those things all the time.

>  100% cpu use, continuous for 10 mins after startup

Too bad it isn't highly reproducible. If there aren't reproducible steps, then without a pref profile with Thunderbird symbols it's going to be difficult to identify.


> Possibly associated with a relatively large number of new mails dealt with
(imap access; filters run and distribute to folders) in one chunk (laptop
boot-and-login the morning after a day off work).

Is there a particular reason you mentioned this, and do yo still think this is likely?

(In reply to Wayne Mery (:wsmwk) from comment #21)
> Is there a particular reason you mentioned this, and do yo still think this
> is likely?

Only that's what came to mind.  I think it's at least possible; I don't recall
getting the issue later in the work day.  Should I try to get a coredump?

One sample from this morning:

(gdb) bt
#0  0x00007f0a7cf4ea04 in nsTSubstring<char>::Capacity() const () from /usr/lib64/thunderbird/libxul.so
#1  0x00007f0a7cf4ea68 in nsTSubstring<char>::MutatePrep(unsigned int, char**, mozilla::detail::StringDataFlags*) ()
   from /usr/lib64/thunderbird/libxul.so
#2  0x00007f0a7cf4ee52 in nsTSubstring<char>::ReplacePrepInternal(unsigned int, unsigned int, unsigned int, unsigned int) ()
   from /usr/lib64/thunderbird/libxul.so
#3  0x00007f0a7cf50229 in nsTSubstring<char>::Assign(char const*, unsigned int, std::nothrow_t const&) () from /usr/lib64/thunderbird/libxul.so
#4  0x00007f0a7cf50304 in nsTSubstring<char>::Assign(char const*) () from /usr/lib64/thunderbird/libxul.so
#5  0x00007f0a7cff39e4 in mozilla::Preferences::GetCString(char const*, nsTSubstring<char>&, mozilla::PrefValueKind) ()
   from /usr/lib64/thunderbird/libxul.so
#6  0x00007f0a7cff3c50 in nsPrefBranch::GetCharPref(char const*, nsTSubstring<char>&) () from /usr/lib64/thunderbird/libxul.so
#7  0x00007f0a7ccf3b2b in nsMsgIncomingServer::GetCharValue(char const*, nsTSubstring<char>&) () from /usr/lib64/thunderbird/libxul.so
#8  0x00007f0a7ccf6051 in nsMsgIncomingServer::GetHostName(nsTSubstring<char>&) () from /usr/lib64/thunderbird/libxul.so
#9  0x00007f0a7ce09274 in nsImapProtocol::SetupWithUrl(nsIURI*, nsISupports*) () from /usr/lib64/thunderbird/libxul.so
#10 0x00007f0a7ce09f6d in nsImapProtocol::LoadImapUrl(nsIURI*, nsISupports*) () from /usr/lib64/thunderbird/libxul.so
#11 0x00007f0a7cdc5b2c in nsImapIncomingServer::LoadNextQueuedUrl(nsIImapProtocol*, bool*) () from /usr/lib64/thunderbird/libxul.so
#12 0x00007f0a7ce292d8 in (anonymous namespace)::SyncRunnable2<nsIImapServerSink, nsIImapProtocol*, bool*>::Run() ()
   from /usr/lib64/thunderbird/libxul.so
#13 0x00007f0a7cfd086b in nsThread::ProcessNextEvent(bool, bool*) () from /usr/lib64/thunderbird/libxul.so
#14 0x00007f0a7cfd91ec in NS_ProcessNextEvent(nsIThread*, bool) () from /usr/lib64/thunderbird/libxul.so
#15 0x00007f0a7d3fc46a in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from /usr/lib64/thunderbird/libxul.so
#16 0x00007f0a7d3d0769 in MessageLoop::Run() () from /usr/lib64/thunderbird/libxul.so
#17 0x00007f0a7ee7984c in nsBaseAppShell::Run() () from /usr/lib64/thunderbird/libxul.so
#18 0x00007f0a7fcf1ade in nsAppStartup::Run() () from /usr/lib64/thunderbird/libxul.so
#19 0x00007f0a7fd8825f in XREMain::XRE_mainRun() () from /usr/lib64/thunderbird/libxul.so
#20 0x00007f0a7fd89069 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) () from /usr/lib64/thunderbird/libxul.so
#21 0x00007f0a7fd89530 in XRE_main(int, char**, mozilla::BootstrapConfig const&) () from /usr/lib64/thunderbird/libxul.so
#22 0x000055a0f462e556 in do_main(int, char**, char**) ()
#23 0x000055a0f462dcad in main ()

Lets do another round of perf record:

# Run Thunderbird, wait for high cpu usage (or keep the current cpu hungry Thunderbird running)

# Call profiling tool:
perf record -g -p `pidof thunderbird` -- sleep 10

# Create file with report:
perf report --stdio -n >out.perf

# Feel free to attach to the bugreport following files:
perf.data
out.perf

Thank you.

Created attachment 1499112 [details]
perf report output

Annoyingly, bugzilla throws a fit when I try to attach the raw per capture,
either plain or compressed.

Thanks for the reply. From the perf report there seems to be a missing symbols for thunderbird, please make sure you have debuginfo installed for thunderbird by:

sudo dnf debuginfo-install thunderbird

Sorry I didn't mentioned that earlier.

Created attachment 1500200 [details]
perf report output

Created attachment 1500201 [details]
raw perf data

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Still current on f28.

Also getting regular crashes, always during this high-activity period symptom.  This in on thunderbird 60.4.0 / fedora 28.  See https://bugzilla.redhat.com/show_bug.cgi?id=1661891
The resulting dump information has recently been large enough that ABRT refuses to upload it, which might imply a memory leak.

The crashes tend to result in full re-downloads of some mail folders after restart, which is painful since I'm on a restricted-monthly-bytes connection.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Just for the records, the bug with Thunderbird using 100% still exists up to Fedora 32 with the latest thunderbird-78.3.1-1.fc32.x86_64 package. It has not been fixed.

No add-ons installed, all accounts freshly configured, after some time Thunderbird uses 100% CPU for no apparent reason. Goes on for hours. Don't know if it will ever end, my notebook is overheating and gets unusable. Thunderbird seems to operate fine, can be used as normal, just a little bit slower because it burns through 1 CPU core in background.

When I quit Thunderbird it continues for some time but then eventually ends.

No idea how to reproduce. It just happens after some time, sometimes sooner, sometimes later. Sometimes several times a day, sometimes not once for weeks.

when you encounter the issue, while Thunderbird is still responsive, use https://github.com/thunderbird-conversations/thunderbird-conversations/wiki/Profiling-Conversation's-Performance to capture a profile.

You may need to use a Thunderbird provided download from https://www.thunderbird.net/

Thank you very much for your response, I will try to do that. "Unfortunately", the bug hasn't occurred during the last 10 days. I totally understand that neither the Fedora nor the Mozilla people can do much as long as nobody who's affected can provide more information to track down this rare problem.

@vseerror ,

Unfortunately I see this issue daily on my laptop on Fedora 35. here is the requested profiling info from idle Thunderbird 91.4.0 from Fedora repo consuming almost 2 CPU cores https://share.firefox.dev/31K689w


Cheers, Oleg.

@oleg.malashenko

More information please. For example, What are you doing during this period?  Moving the mouse?

Most of the wait, 58%, is under PollWrapper. Most of the rest is in graphics rending.

Hi Wayne,

Thank you for the quick response.


> More information please. For example, What are you doing during this period?  Moving the mouse?

I am doing absolutely nothing, not even touching the mouse. The reproducibility and symptoms are consistent with the other reports in this thread, thus I decided to post into a CLOSED EOL thread to keep the history.


> Most of the wait, 58%, is under PollWrapper. Most of the rest is in graphics rending.

And it total it takes about 2 full CPU cores of AMD Ryzen 9 5900HX (160-190%). Initially everything works fine when Thunderbird just started, but after a random period of time (sometimes minutes, sometimes hours) it turns into a CPU hog.

I am not familiar with Thunderbird rendering code, but maybe it has something to do with redraw being triggered too often? The following points are just my guesses:

* broken timer firing constantly
* redraw event arriving too often (maybe as a side effect of a previous redraw cycle?)
* some sort of invisible animation requiring constant and quick redraw
* unprotected access to 'redraw required' flag

I am happy to assist with more testing and debugging if needed.

Hope that helps.

For the record: I reported a similar bug with full perf/gdb/strace log upstream here, please feel free to join if appropriate:

https://bugzilla.mozilla.org/show_bug.cgi?id=1752641

I have reason to believe the (visible) culprit of this is the "progress bar" thing in the thunderbird status bar, which is showing a sort of moving color wave pattern whenever this condition occurs to me.

Hiding the status bar (View->Toolbars->Status bar) makes the TB CPU usage drop significantly.

This also vibes with the large amout of libxul calls seen in the perf traces, as xul is drawing the user interface.

Now, the real trigger might be that something in the actual mail fetching thread gets stuck somehow and never completes, thus keeping the status bar animation on, but the main driver of the CPU usage might be the status bar animation itself.

OlegM, I think there is sufficient information in the various upstream bug reports.  If hiding the status bar helps your situation, then it is a match to those bugs and no further information is needed.

Thank you Wayne, I'll follow the upstream bug reported by tychokirchner.