Description of problem: Since last urpmi --auto-update thunderbird is so slow that it's unusable. I tried to run it with --safe-mode to disable extensions and themes : same result I dit let it run all the night just in case it needed to "process" somehow it's database(s). At the end of the night it coredumped wit this message : $ thunderbird --safe-mode --jsconsole ATTENTION: default value of option mesa_glthread overridden by environment. out of memory: 0x0000000000000048 bytes requested Exiting due to channel error. Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=2130.34) Erreur de segmentation (core dumped) At least one other case of this problem is reported on Mageia Online french forum : https://www.mageialinux-online.org/forum/topic-29468+thunderbird-crash.php Version-Release number of selected component (if applicable): thunderbird-102.5.0-1.mga8 How reproducible: Always : I just run thunderbird on my laptop and boom Steps to Reproduce: 1. Open a console 2. Run thunderbird 3.
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) => davidwhodginsAssignee: bugsquad => nicolas.salguero
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 ?