If people experience that Thunderbird no longer starts after being updated to 146.0-1.fc43: this is a bug and it is reported as BZ#2423824.
The easiest temporarily mitigation for now is to downgrade and avoid updating thunderbird until the issue is fixed. As the default downgrade would go down to version 140, I suggest to use the following downgrade command to only return to 145: dnf downgrade https://kojipkgs.fedoraproject.org//packages/thunderbird/145.0/1.fc43/x86_64/thunderbird-145.0-1.fc43.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/thunderbird/145.0/1.fc43/x86_64/thunderbird-librnp-rnp-145.0-1.fc43.x86_64.rpm
Keep in mind that dnf would automatically re-update thunderbird to the broken version. If you want to do dnf update without re-updating to the broken thunderbird version, you might temporarily use this update command: dnf update --exclude=thunderbird --exclude=thunderbird-librnp-rnp
Hopefully, it is fixed with another update soon 
If you are not affected by this bug, there is no need to downgrade (there is no indication that that this is a security bug or so).
However, if you have further information that could be useful to find and fix the bug, feel free to add your data to the bug report mentioned above. You can also post here if there is something to discuss about it…
I think it’s unreasonable to have package for 24 hours in testing before pushing it out. There should be a 72 hours minimum time period (unless the update fixes an important CVE)
As mentioned in the bodhi ticket, “stable by time” is actually 7 days. Only if sufficient users report positive karma after testing (“+1”), it can reach “stable by karma” with 3 users reporting +1 but no user reporting -1. That said, I agree that the number of 3 is not much (especially in cases that go along with the absence of standardized test cases and generally in a test system that has no trust levels or something comparable), and it might be worth to increase that number. But I think that is not a thunderbird package-specific thing, but a general policy on packages. I am actually not sure who is reponsible for that, but in case of a doubt, I presume it is the decision of the QA team.
Yes, this is under discussion at the moment. See @adamw 's suggestions here (with links to tracking tickets in Github).
2 Likes
It’s not just me with this issue, others reproduced it already. That’s why I also opened something about it here, to avoid more tickets that lead to more bug reports. Another user with that issue has aarch64 / Asahi Remix, so seems not even x86_64 specific. What seems to be in common so far is KDE. Something else not everyone has is a master password, which might trigger some lines that are not called otherwise (but don’t know if others have that correlation too). Confinement of SELinux seems to not impact the bug. Anyway, there’s a segFault with coredump, that suffices to assume a bug if the system is untainted and without external repos/packages.
If people want to report further cases of this bug, please also add it to the bugzilla report BZ#2423824, not only in bodhi.
Also, it would be useful to add more details on how your thunderbird is configured/customized (e.g., do you have a master password to start thunderbird, etc.), and what Fedora variant you use (e.g., F43 KDE or Fedora Silverblue, etc.) and what customizations are done to Fedora (e.g., third party packages or repos, or other types of customizations). You might also want to add log files containing the error (e.g., an extract containing the entries from journalctl --no-hostname --boot=0 of the time before, during, after the crash). It would be useful for the maintainer to understand the circumstances in which thunderbird breaks and in which it does not break, and how manifests of the crash differ.
I suspect 146.0.1 upstream fixes this. I’m running a build now and will update the update when it’s done, it’ll take about 5 hours. Sorry for the trouble. From a quick look, whether you see the crash depends on your screen size. So that’s why some people saw it working fine and +1ed it 
I’ll link this from my Bodhi policy change suggestions…
1 Like
No worries. I got a little lazy in the recent months about testing all apps I depend on. If I would have done so, I likely could have prevented the push. And whatever test cases we deploy, we cannot identify everything, and if this really depends on the screen size, I think even 50 tests wouldn’t have guaranteed to get it identified before pushing. That said, it might be indeed useful to create test cases for thunderbird (much issues I experienced over time using this app did not occur immediately at opening, remaining hidden when just testing opening + closing). But given the nature of the application, I feel insecure if we can define test cases that both cover most that can cause issues (be effective) and still do not force testers to invest a lot of time (be efficient → e.g., a worst case would be if testers have to setup accounts for testing different protocols or so).
People who want to test the new build immediately once it’s ready, feel free to do so here: Making sure you're not a bot!
Keep in mind this is testing after being built, and has to be considered as such.
I’ll do testing later today or tomorrow and provide feedback here & in the BZ#2423824. Thanks for taking care Adam
Update is up here, it won’t be on mirrors for a bit, though. You can download direct from Koji at the link Chris gave, and give feedback in Bodhi.
1 Like
Thanks, just tested & reported in bodhi, the issue remains unchanged. I am uploading a new log of the test with thunderbird-146.0.1-1.fc43.x86_64.rpm & thunderbird-librnp-rnp-146.0.1-1.fc43.x86_64.rpm to the BZ# ticket in a minute, incl. coredump etc.
However, thanks for the quick response and efforts
1 Like
yeah, it seems like maybe 146.0.1 only included the fix for a different crash to do with localization, or something? It really looked from the upstream issue like it was going to include the fix for this 
I will try again today, since stransky doesn’t seem to be around AFAICT.
1 Like
Can anyone give the latest F43 build a quick go and see if it’s finally fixed? It’s not done on all arches yet, but it’s done on x86_64.
1 Like
I assume its the build from here: Making sure you're not a bot! → I just tested from there thunderbird-146.0.1-2.fc43.x86_64.rpm and thunderbird-librnp-rnp-146.0.1-2.fc43.x86_64.rpm → seems to work
1 Like
Thanks! Yes, that was just a direct link to the package from that build.
1 Like
Perfect! Thanks for the quick efforts 
Supplement: the update that fixes the bug has been pushed to stable. If anyone experiences this bug, just do sudo dnf update --refresh and then do the update(s). Then, restart Thunderbird. If this does not work, reboot after the update and then try again.
If this does not work, you likely have a different problem and should open a new topic.
2 posts were merged into an existing topic: Thunderbird crashes on Asahi and/or aarch64
This message is probably unrelated to the problem being described. I get the same message if I start Flathub Thunderbird from the terminal, yet it runs fine for me without crashing.
I think the issue occurring on aarch64 is a different one. Please read my last post in the bug report BZ#2423824 (comment 32)