Thunderbird 140 uses high CPU on macOS 10.15 and crashes on quit
Categories
(Thunderbird :: General, defect, P2)
Tracking
(thunderbird_esr140+ affected)
People
(Reporter: oe-tronic, Assigned: gsvelto)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Attachments
(3 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:140.0) Gecko/20100101 Firefox/140.0
Steps to reproduce:
On macOS 10.15.7 I have updated from Thunderbird 128.12.0esr to Thunderbird 140.0.1esr.
Since the update I notice a high CPU load (and fan noise) every time I open the program. The same on another Mac. Both are Intel Macs.
Every time I quit the program, it crashes.
I have tried starting the program in safe mode, which didn't change anything.
In the Activity Monitor app I noticed a second process named “thunderbird” (lowercase). Once I kill that process, the CPU load is much lower.
This is an excerpt from the beginning of the crash report in macOS, which seems to point to some of the dylibs:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [4389]
Application Specific Information:
crashed on child side of fork pre-exec
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_malloc.dylib 0x00007fff6e769e41 nanov2_forked_calloc + 7
1 libsystem_malloc.dylib 0x00007fff6e754f59 malloc_zone_calloc + 99
2 libsystem_malloc.dylib 0x00007fff6e754ed9 calloc + 24
3 libobjc.A.dylib 0x00007fff6d3e9603 allocateBuckets(unsigned int) + 29
4 libobjc.A.dylib 0x00007fff6d3e9096 cache_fill + 283
5 libobjc.A.dylib 0x00007fff6d3e8b27 lookUpImpOrForward + 530
6 libobjc.A.dylib 0x00007fff6d3e8399 _objc_msgSend_uncached + 73
7 libxpc.dylib 0x00007fff6e7f389e xpc_atfork_child + 125
8 libSystem.B.dylib 0x00007fff6b580ab8 libSystem_atfork_child + 59
9 libsystem_c.dylib 0x00007fff6e5fc8ad fork + 40
10 XUL 0x00000001127d8333 0x10cbf8000 + 96338739
11 XUL 0x000000011165a0ce 0x10cbf8000 + 77996238
12 XUL 0x00000001116844a8 0x10cbf8000 + 78169256
13 XUL 0x000000011168b086 0x10cbf8000 + 78196870
14 XUL 0x000000011168b65f 0x10cbf8000 + 78198367
15 org.mozilla.thunderbird 0x000000010b816a98 0x10b816000 + 2712
16 libdyld.dylib 0x00007fff6e59ccc9 start + 1
Actual results:
High CPU load, Thunderbird crashes on quit every time.
Expected results:
Normal CPU load, no crashes.
I have also trashed Thunderbird and the profile folder (backupped to an external drive).
Even after a fresh install, with a fresh profile, from the first moment I started Thunderbird, it showed the same issues.
I also noticed this and it seems to be caused by an extra process running. When starting, the Activity monitor shows one process called "Thunderbird" and one process called "thunderbird". After killing the "thunderbird" process, the CPU activity goes down and everything still seems to work as normal.
(In reply to Wayne Mery (:wsmwk) from comment #2)
Does bug 1662759 comment 28 help?
No. Thunderbird was unchecked already.
(In reply to dittnamn from comment #3)
I also noticed this and it seems to be caused by an extra process running. When starting, the Activity monitor shows one process called "Thunderbird" and one process called "thunderbird". After killing the "thunderbird" process, the CPU activity goes down and everything still seems to work as normal.
Same here. When I kill that “thunderbird” (uncapitalized) process, CPU usage is normal and the program won't crash.
To reproduce this, just install Thunderbird 140 on a Mac running macOS 10.15.7 (Catalina).
I think it doesn't come from updating the program, because I trashed Thunderbird and the profile folder.
|
||
Updated•23 days ago
|
|
||
Comment 7•22 days ago
|
||
I am unable to reproduce either the CPU use or the crash on my Mac (Sequoia 15.5, M4 Pro) with 140.0.1esr.
|
||
Updated•22 days ago
|
🟠 Follow-up: Additional findings for Bug 1977514 (macOS 10.15.7, Thunderbird 140.0.0 & 140.0.1)
This report was written with the help of ChatGPT to improve clarity and technical structure.
However, all system behavior was manually observed, reproduced, and verified by me.
🧩 Summary of observed behavior:
On macOS 10.15.7 (Catalina), launching Thunderbird 140.0.0 or 140.0.1 results in:
an additional background process named thunderbird (lowercase),
very high CPU usage by both Thunderbird and thunderbird,
and, upon quitting the app, a crash dialog stating:
"thunderbird quit unexpectedly" (referring to the subprocess).
Importantly, this happens without any user interaction — simply opening the application is enough.
🔬 Technical details:
In Activity Monitor, immediately after launch:
Thunderbird (main process): ~44% CPU
thunderbird (subprocess): ~57.5% CPU
This causes the Mac's fans to spin up rapidly.
Quitting the application results in a consistent crash message.
Crash log excerpt:
crashed on child side of fork pre-exec
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
libsystem_malloc.dylib → nanov2_forked_calloc
Earlier Thunderbird versions did not show this behavior.
✅ Workaround tested:
By launching Thunderbird with:
MOZ_DISABLE_FORK=1
I was able to completely prevent the bug.
Results:
No subprocess spawns.
No excessive CPU usage.
No crash on quit.
Thunderbird runs stably and quietly.
🧠 Possible cause (speculative):
macOS 10.15 is a legacy OS and no longer receives kernel updates or deeper system-level patches.
It's possible that newer subprocess/fork behavior used in Thunderbird is not fully compatible with 10.15.
This would explain why the crash occurs before the forked process completes initialization.
This is speculation, but the workaround strongly suggests a relationship.
💡 Suggestions for Thunderbird:
Consider defaulting to MOZ_DISABLE_FORK=1 on macOS 10.15.x
Or: add a clear note in documentation or crash-recovery guides
Or: disable fork-based architecture selectively for unsupported macOS versions
|
||
Comment 9•21 days ago
|
||
Hi I can confirm dittnamn's finding that there are two thunderbird processes. Killing
one of them (with kill <pid> from a Terminal), the one with the higher pid solves the
problem of CPU usage and seems also to solve the crash on quitting thunderbird.
I don't think that this is due to a 'legacy' behaviour of the fork mechanism, this is
a standard on UNIX systems for a long time now. The question that arises is why
is thunderbird forking a process at all (which seems to be of no use for normal
thunderbird behaviour, after killing it everything runs fine in thunderbird).
Is it possible to downgrade thunderbird in order to check which version introduced
the bug? I would prefer if I don't have to do an uninstall / install circle since I am
using it in a production environment. But if this is the only way to do it, I would
also do that. Please let me know what is the best way to downgrade thunderbird.
Best regards,
- Johannes
|
Reporter | |
Comment 10•20 days ago
|
||
Another observation:
Betterbird 140.0.1esr-bb6 works without these problems here. And in Activity Monitor I don't see the subprocess running.
|
||
Comment 11•20 days ago
|
||
a similar problem here:
https://connect.mozilla.org/t5/discussions/thunderbird-140-0-1esr-64-bit-causing-high-cpu-usage-and/td-p/101019
I completely solved the problem by going back and re-installing Thunderbird 128.11.1esr on my MacBook Pro running Catalina 10.15.7. No more overheating, no more continuous fan running. Thunderbird 140.0.1esr needs a fix.
|
||
Comment 12•19 days ago
|
||
Confirmed due to multiple reports
|
||
Comment 13•18 days ago
|
||
I don't know why, but it's the crash reporter. MOZ_CRASHREPORTER_DISABLE=1 should also stop it.
|
|
Reporter | |
Comment 14•18 days ago
|
||
(In reply to Geoff Lankow (:darktrojan) from comment #13)
I don't know why, but it's the crash reporter.
MOZ_CRASHREPORTER_DISABLE=1should also stop it.
I can confirm that launching Thunderbird with 'MOZ_CRASHREPORTER_DISABLE=1' achieves the same result as launching it with 'MOZ_DISABLE_FORK=1'.
Either option prevents the 'thunderbird' process, the high CPU load, and the crash when the program is quit.
|
|
||
Comment 15•18 days ago
|
||
I suspect bug 1620998 is the cause here. The timing is right, I see the problem in 139 but not in 138. (I tried to use mozregression but couldn't reproduce the problem that way.) Gabriele, could you take a look please?
|
|
||
Comment 16•18 days ago
|
||
For completeness, I just checked Firefox and it does not appear to have this problem. So I guess we've got something configured badly somewhere?
|
|
||
Updated•18 days ago
|
|
|
||
Updated•18 days ago
|
|
|
||
Comment 17•18 days ago
|
||
Setting to sev 3 since there's a work-around in comment 13
|
Assignee | |
Comment 18•17 days ago
|
||
Is this still happening after bug 1964600? I had to deploy some macOS 10.15-specific fixes there. Anyway, I'll test this tomorrow and see if I can repro. Leaving the NI? for now so I don't forget.
|
|
||
Comment 19•16 days ago
|
||
I'm seeing the same thing in a 142.0b1 candidate build.
|
|
Assignee | |
Comment 20•16 days ago
|
||
I'm seeing this on startup. Thunderbird appears to spawn a second process (likely the crash helper process) and both processes get stuck at 100% CPU usage doing nothing. I'm trying to figure out why.
|
|
Assignee | |
Comment 21•16 days ago
|
||
At a first glance this appears to be a problem with the second fork() call in macOS 10.15. We already had a number of issues with it because it does some unexpected stuff (like allocating memory in userspace) and this might be yet another manifestation of the problem. I'll try to replace it with posix_spawn() and see if it fixes the issue. I honestly don't know why this affects Thunderbird but not Firefox, but it could be related to how we hook malloc().
|
|
Reporter | |
Comment 22•16 days ago
|
||
(In reply to wolfgang from comment #14)
(In reply to Geoff Lankow (:darktrojan) from comment #13)
I don't know why, but it's the crash reporter.
MOZ_CRASHREPORTER_DISABLE=1should also stop it.I can confirm that launching Thunderbird with 'MOZ_CRASHREPORTER_DISABLE=1' achieves the same result as launching it with 'MOZ_DISABLE_FORK=1'.
Either option prevents the 'thunderbird' process, the high CPU load, and the crash when the program is quit.
Another observation: I am currently using an AppleScript to launch Thunderbird and thus avoid the second process. However, it seems to make no difference what command I use. For example, 'MOZ_GOODMORNING' has the same effect as 'MOZ_CRASHREPORTER_DISABLE=1'.
I don't understand enough about this as a layman, but does it make sense to you?
|
|
Assignee | |
Comment 23•16 days ago
|
||
I suspect the bug is caused by a race or a specific set of conditions within the main process at launch time. Disabling crash reporting (MOZ_CRASHREPORTER_DISABLE=1) will always fix it, but any other option might perturb the startup process enough to avoid the race and make Thunderbird work anyway. It's just luck.
|
|
Assignee | |
Comment 24•16 days ago
|
||
Working on this but struggling to build a patch to work around the issue. My first thought was that the crash was happening when we called fork() again to daemonize the crash helper, but that's not the case and I should have known. The issue was introduced with bug 1620998 and there's only one fork() invocation there. The problem is happening on the child side of that fork() call, because the system returns from it. So I need to replace that with a posix_spawn() and then I'd fork() again but I'm worried that I'd just move the problem around. So I'll like have to do a double posix_spawn() which complicates things a bit, mostly because the current version of the nix crate we have in-tree doesn't have a safe wrapper around posix_spawn().
|
|
||
Comment 25•15 days ago
|
||
Never a submitted crash with signature?
|
|
Reporter | |
Comment 26•15 days ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #25)
Never a submitted crash with signature?
Do you mean a crash ID?
The last crash report saved here is from 2023.
I never turned it off.
|
|
Assignee | |
Comment 27•15 days ago
|
||
|
|
Assignee | |
Comment 28•15 days ago
|
||
|
|
Assignee | |
Comment 29•15 days ago
|
||
|
||
Comment 30•2 days ago
|
||
|
|
||
Comment 31•2 days ago
|
||
|
||
Comment 32•2 days ago
|
||
Backed out for causing build bustages
Backout link: hg.mozilla.org/integration/autoland/rev/c27768fa3d1d7ef7b94c4b429bb37886774d5d42
Failure log -> ERROR - error: function daemonize is never used
|
|
||
Comment 34•10 hours ago
|
||
Description
•