User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

• Connect to WIFI, run TB on Debian 10 Buster
• Suspend Laptop
• Go somewhere else where this WIFI is not visible
• Resume Laptop

Actual results:

After resume, sometimes (once a day) TB keeps one core busy forever (100%), a wheel is spinning. It seems to be related to networking (see attached strace log: recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN).
Apart from that TB is still responsive and can be closed cleanly.

Please also see attached gdb and perf log.

Expected results:

TB should not grill my cpu, just try again later on connection drop.
Note that this bug has been present for long, at least since version 78.14.

The very same scenario happens to me @tychokirchner

All right. Thanks to the comment 42 of Ralf Ertzinger in bug 1321864 https://bugzilla.redhat.com/show_bug.cgi?id=1321864 I think I can add something. He wrote:

I have reason to believe the (visible) culprit of this is the "progress bar" thing in the TB 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.

So, in current TB v102.6.0 we have a spinninng "half circle" in the top main toolbar, when there is activity. Indeed, as described above, on resume TB eventually starts some activity which never completes. However hiding the main toolbar or switching to the calendar tab substantially reduces CPU usage - to essentially zero.
Further, in my case, on the bottom toolbar a text says that my google calendar is being synchronized. So maybe the code, which never completes, may be within the calendar module. However, it's not plausible why a simple spinning animation is such a CPU hog. So, I think two things should be fixed: google calendar synchronization and TB animation performance.

Thanks.
Tycho

Tycho, Thanks for the update.

A performance profile would nail it down even better https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance
Might want to use a build from thunderbird.net.

I added a performance profile here. Used version: 102.11.0 (64-bit) (from Debian Bullseye repository).
The following errors were displayed in the error console, not sure they are related though...:

got error in _asyncTrackerListener.handleError(): 19: constraint failed
[calCachedCalendar] replay action failed: <unknown>, uri=googleapi://foobar@gmail.com/?calendar=foobar%40gmail.com, result=, operation=[object Object]

All right, I think I have finally found a way to reproduce. It seems to be indeed the calendar. To reproduce:

• setup a google calendar account in TB
• switch to the calendar tab and make sure, that all notifications are dismissed
• configure your network so that it points to an invalid gateway and DNS address. For instance, my normal router address is 192.168.178.1, I changed gateway and DNS both to 192.168.178.189
• rightclick on your google cal and hit "Synchronize Calendars"
• switch to main (inbox) tab and see the wheel spinning. Eventually it is necessary to hit "Synchronize Calendars" multiple times, but I never had to do it more than four times.
• verify that the spinning wheel never stops. Eventually, on re-establishing the internet connection "fast enough", the spinning stops, but in my experiments, after spinning for longer than 10 minutes, it never stopped again until closing TB.

Hoping to finally see this fixed. In case you have questions or cannot reproduce just drop me a note here.
Thanks, Tycho

Other network performance issues https://mzl.la/3JTZ8ty

(In reply to tychokirchner from comment #4)

I added a performance profile here. Used version: 102.11.0 (64-bit) (from Debian Bullseye repository).
The following errors were displayed in the error console, not sure they are related though...:

got error in _asyncTrackerListener.handleError(): 19: constraint failed
[calCachedCalendar] replay action failed: <unknown>, uri=googleapi://foobar@gmail.com/?calendar=foobar%40gmail.com, result=, operation=[object Object]

Thank you for the profile. The feedback is "We can see the "RefreshDriverTick - Tick reasons: HasImageAnimations" markers keep going forever. So there's somewhere in the UI an animated image that remains visible forever"

If the issue also happens in version 115, then we need to determine the source of the animation.

More info...
"The profile contains the processcpu data, and Thunderbird doesn't use 100% of a core. [So] it could be X doing its magic"