1752641 - High CPU-Load (100% of one core) on suspend and WIFI connection-drop - network connectivity

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking, defect)

Description

[tychokirchner]

Attachment: logs.zip

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.

Comment 1

[José María Fernández]

The very same scenario happens to me @tychokirchner

Comment 2

[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

Comment 3

[Wayne Mery (:wsmwk)]

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.

Comment 4

[tychokirchner]

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://[e-mail]/?calendar=foobar%40gmail.com, result=, operation=[object Object]

Comment 5

[tychokirchner]

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

Comment 6

[Wayne Mery (:wsmwk)]

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

Comment 7

[Wayne Mery (:wsmwk)]

(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://[e-mail]/?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.

Comment 8

[Wayne Mery (:wsmwk)]

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"

Comment 9

[tychokirchner]

I created a fresh TB profile a month ago and can no longer see the issue in TB 128.5.0esr (64-bit) on Debian 12 Bookworm. Suggesting to close.
Thanks, Tycho

Comment 10

[Magnus Melin [:mkmelin]]

-> WFM per comment 9

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to tychokirchner from comment #9)

I created a fresh TB profile a month ago and can no longer see the issue in TB 128.5.0esr (64-bit) on Debian 12 Bookworm. Suggesting to close.
Thanks, Tycho

Are you still good?
And did you determine what specific aspect of the new profile might have caused the problem to go away?