| Summary: | Thunderbird very slow then crashes even with --safe mode after last urpmi --auto-update | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Maat <maat-ml> |
| Component: | RPM Packages | Assignee: | Nicolas Salguero <nicolas.salguero> |
| Status: | NEW --- | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | davidwhodgins, zen25000 |
| Version: | 8 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | thunderbird-102.5.0-1.mga8.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: |
Htop output
lenovo laptop w/8GB ram running TB and FF Mga8 for comparison |
||
|
Description
Maat
2022-11-26 09:07:45 CET
I also tried to reboot the computer, change kernel, check the js console in search of noticeable errors without success. Seems it's a "low level" problem... It may be only impacting some configurations or usage. I started thunderbird, and using htop to monitor it's memory usage. It goes up and down even though it's currently in the background, but so far keeps returning to the same amount of ram used. With 16GB of ram on my system it would take a while before any memory leak would force the system to start swapping. With 32GB of swap on my ssd drive, quite a while before it would crash. Assigning to Nicolas, though I doubt we'll be able to do anything other then wait for the next thunderbird esr update. Maat, how much ram/swap is in your system, and what architecture (from "rpm -q -i thunderbird|grep Arch"). Use "free -m" to get ram/swap available/used. CC:
(none) =>
davidwhodgins Hi Dave,
So for the 1st question :
$ LAN=C rpm -q -i thunderbird|grep Arch
Architecture: x86_64
for the second :
$ LANG=C free -m
total used free shared buff/cache available
Mem: 31809 4614 23926 1091 3268 25659
Swap: 59903 0 59903
Bonus :
ps -eFl | grep thunderbird
4 R maat 83319 77111 99 80 0 - 1541161 - 3154984 4 16:59 pts/1 00:04:23 thunderbird --safe-mode --jsconsole
0 S maat 86237 83319 0 80 0 - 606509 do_sys 97200 7 16:59 pts/1 00:00:00 /usr/lib64/thunderbird/thunderbird -contentproc -childID 1 -isForBrowser -prefsLen 165607 -prefMapSize 380819 -safeMode -parentBuildID 20221116090026 -appDir /usr/lib64/thunderbird 83319 tab
Created attachment 13534 [details]
Htop output
Bonus 2 : the output of htop.
One TB process is eating between 100% and 130% on one Core line.
but the laptop is far from its RAM limit.
Looks like in addition to a memory leak, it's using excessive cpu. See if https://rainbow.chard.org/2013/02/19/thunderbird-high-cpu/ helps. Created attachment 13535 [details]
lenovo laptop w/8GB ram running TB and FF Mga8 for comparison
Added htop from my laptop for comparison as I was reading this and decided to check.
There are several pages of thunderbird processes but not doing much other than occasional short bursts of activity on one core.
I have only one 'remove duplicates' addon IIRC.CC:
(none) =>
zen25000 (In reply to Dave Hodgins from comment #5) > Looks like in addition to a memory leak, it's using excessive cpu. > See if https://rainbow.chard.org/2013/02/19/thunderbird-high-cpu/ helps. Il have already the higher value for mail.db.idle_limit I tested 102.5.0 and 105.4.2 from https://www.thunderbird.net/ : the behavior is slightly more responsive but the process eating nearly one CPU line is there Quite different : version 91.13.1 from https://www.thunderbird.net/ starts fast and seems to work as expected. But this one eats a lot more RAM. (Nota: my profile is really big: 100+G with 10+ IMAP accounts and lots of archives) So 1st conclusion : the problem is still in the upstream built version = It's not a packaging issue. 2nd conclusion : it might be global to all 102.x but i did not check versions earlier than 102.4.2 Probably best to report it at https://www-archive.mozilla.org/support/thunderbird/bugs using the latest build. Working directly with them will hopefully make solving it faster. Insightful, thanks Dave. After further tests 91.13.1 version ends also in the same problem... it just needed a night to show up. Currently i'm testing with 91.13.1 BUT i booted on 5.18.11-desktop-1.mga8 And it seems better. Could it be an issue with something in the new 6.x kernel ? |