Brummolix
AaR run may trigger Thunderbird crash
Starting a AaR run (by selecting it from the Tools menu and confirming the popup) may trigger Thunderbird 60.2.1 (x86_64) to crash: https://bugzilla.mozilla.org/show_bug.cgi?id=1517478
Socorro crash analysis just to provide some (searchable) context:
Top 10 frames of crashing thread:
0 libxul.so nsQueryReferent::operator /build/thunderbird-Z9Pyl0/thunderbird-60.2.1+build1/xpcom/base/nsWeakReference.cpp:152 1 libxul.so nsCOMPtr_base::assign_from_query_referent /build/thunderbird-Z9Pyl0/thunderbird-60.2.1+build1/xpcom/base/nsCOMPtr.cpp:117 2 libxul.so nsMsgSearchSession::TimerCallback /build/thunderbird-Z9Pyl0/thunderbird-60.2.1+build1/xpcom/base/nsCOMPtr.h:595 3 libxul.so nsTimerImpl::Fire /build/thunderbird-Z9Pyl0/thunderbird-60.2.1+build1/xpcom/threads/nsTimerImpl.cpp:701 4 memfd:pulseaudio (deleted) memfd:pulseaudio @0xa711fff 5 libc-2.27.so libc-2.27.so@0x130ea5 6 libxul.so nsTimerEvent::Run /build/thunderbird-Z9Pyl0/thunderbird-60.2.1+build1/xpcom/threads/TimerThread.cpp:286 7 libxul.so mozilla::HangMonitor::NotifyActivity /build/thunderbird-Z9Pyl0/thunderbird-60.2.1+build1/xpcom/threads/HangMonitor.cpp:405 8 libxul.so nsThread::ProcessNextEvent /build/thunderbird-Z9Pyl0/thunderbird-60.2.1+build1/xpcom/threads/nsThread.cpp:1040 9 libpthread-2.27.so libpthread-2.27.so@0xb7de
I'm just reporting this here to inform you. Feel free to close the bug any time if you think this is not due to AaR misbehaving. Obviously the crash should not occur and this is more in TB's domain.
updated the bug report at https://bugzilla.mozilla.org/show_bug.cgi?id=1517478#c4
@Brummolix Do you attempted to debug the crash to determine what part of the addon is triggering the crash?
@wsmwk I never saw this crash on my own system. Therefore it is hard to debug for me. @mornau If it is crashing on your system, can you enable the extended logging in the addon preferences? Then it should also write a log file AutoarchiveReloadedLog.txt in the profile directory. With this log file we may see at least what was the last log entry before it crashs. (You might want to cleanup the log file from any personal data before posting it!) (The addon version for TB > version 60 does no longer write this log file as it is build with Thunderbird web extensions and can not write there any longer)
(As previously mentioned on the BMO bug report) I had to give up on using (trying to use) AaR since it was what kept triggering the Thunderbird crashes, and nobody was available in Mozillaland to help debug it back then - but I needed a usable mail client.
I have not downgraded Thunderbird since I first reported this bug (when I was running 60.2.1) so there would be no extended logging if I would run it again. Is there any reason to assume that the debugging situation would be any better if I was to run AaR on TB 60.8.0 now?
@mornau I'm not 100% certain what you are asking, but as I understand it you can be running any 60.x to get the logging suggested by @Brummolix
@wsmwk Hmm, that's not how I interpret @Brummolix's statement here:
(The addon version for TB > version 60 does no longer write this log file as it is build with Thunderbird web extensions and can not write there any longer)
I'm not strictly asking anything, just wondering whether there is any use in me reinstalling AaR at this point and reproducing the crashes - since it seems that the situation we're in regarding the ability to trace this bug is the same as it used to be. Or is there, at this point, any reason to assume we may be able to identify the root cause now when we were not able to do so with the information we have gathered so far?
Any 60.x would be fine. It is always hard to find a bug you can't reproduce on your system. The log file might help.
Please find AutoarchiveReloadedLog.txt attached. Running Thunderbird 60.8.0 (64-bit) on Ubuntu 18.04.3 and AaR 0.9.9.6.2 this issue remains fully reproducible - about 10 seconds after starting a AaR run from the "Tools" menu, TB crashes.
For the purpose of simplifying things, I have disabled AutoArchiving for all accounts except for a newsfeed account ("[REDACTED ACCOUNT 9]") - but I think the same happens for IMAP accounts as well. Before testing, I have disabled all TB extensions I do not strictly require and restarted TB.
Text displayed by the Mozilla Crash Reporter when the crash occurs: mozcrashreporter.txt I have submitted a crash dump by this means, and it should be possible to identify it by the partial reporter e-mail address I provided (where access to Mozillas' Socorro is granted).
@wsmwk The code of add on 0.9.9.6.2 is at https://github.com/Brummolix/AutoarchiveReloaded/blob/0.9.9.6.2/chrome/content/overlay.js
The last log entry is https://github.com/Brummolix/AutoarchiveReloaded/blob/0.9.9.6.2/chrome/content/overlay.js#L297 As no other log entry was written the crash might be raised from any of the following:
- mail3PaneWindow.gFolderDisplay.show(folderToSelect); https://github.com/Brummolix/AutoarchiveReloaded/blob/0.9.9.6.2/chrome/content/overlay.js#L300
- batchMover.archiveMessages(this.messages); (containing the list of >8000 messages) https://github.com/Brummolix/AutoarchiveReloaded/blob/0.9.9.6.2/chrome/content/overlay.js#L310
- one of the things in the complete stopAndSetFinal function https://github.com/Brummolix/AutoarchiveReloaded/blob/0.9.9.6.2/chrome/content/overlay.js#L209
- could be also in the checkForArchiveDone function as this is fired every 500ms https://github.com/Brummolix/AutoarchiveReloaded/blob/0.9.9.6.2/chrome/content/overlay.js#L548
- or it could be also in some of the catch blocks AutoarchiveReloadedOverlay.Logger.errorException(e); like https://github.com/Brummolix/AutoarchiveReloaded/blob/0.9.9.6.2/chrome/content/overlay.js#L315
I hope this analysis may help a bit.
The Mozilla bug has since been closed because "There does not appear to be a version 78 compatible version of Autoarchive" - "not actionable as is".