Thunderbird crashes regularly when autochecking additional IMAP folders that get mail from server-side filters



MailNews Core
Networking: IMAP
2 years ago
a year ago


(Reporter: Teodor, Unassigned)



Windows 7

Firefox Tracking Flags

(Not tracked)


(crash signature)



2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

Not reproducible very well.
I have 4 IMAP Gmail accounts in 38.6.0, tried installing also with a super clean install (removed all TB folders etc.) an older version 38.4.0, same issue. Update to 38.5.1, same issue, 38.6.0, same issue.
After 2 months of fighting this problem, I narrowed it down with great probability to this situation:

I have only 2 of the accounts selected for autocheck in settings (no matter the concrete periods, currently 30 and 40 minutes respectively).

When I have selected a custom folder (label in gmail terms) to include in account's autocheck (right-click - Properties - When Getting New Messages..., Always Check This Folder - checked), TB crashes almost regularly - sometimes 2 hours after start, sometimes 20 hours later, sometimes 3 days later. But it does this Everytime 100% until the 3-rd day. Most of the time it happens without any intervention - TB stays in the background. When I calculate the times I started TB and when it crashes, it ALWAYS happens at a moment when an autocheck is scheduled by TB. It can sustain 2 days autochecking, but at some time it just crashes. The Crash Repoter pops up, TB window closes, and I sent already tens of crash reports. This seriously hinders my experience and I don't want to convert to another client, although I'm at the edge.
I tried turning mail.imap.use_status_for_biff off (false), no change.
The one time (last week) I had left all custom folders unchecked for autocheck (so only Inbox is autocheked periodically), TB sustained 5-6 days with no crash. So I'm almost positive this is the culprit.
Up to 2 months ago I was using 3 pop (gmail) and 2 IMAP (one of them gmail) accounts, for years with NO problems. Then I decided to convert the POPs to IMAP. Deleted them and recreated them as IMAP, also included 2 custom IMAP folders for autocheck in 3 accounts. That's when it started to crash. For 2 months I was hunting for the cause.
I hope this helps to resolve the problem, as well as my countless crash reports.

Actual results:

TB crashes about 2 hours to at most 3 days after being started. Sometimes it also corrupted the local offline cache and I had to patiently wait for hours to reindex/redownload ALL my emails from the server!

Expected results:

TB should not crash intermitently even when staying in background when checking for new mail periodically, when there are other folders selected for autocheck for new mail in addition to the default Inbox.


2 years ago
Component: Untriaged → General
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64

Comment 1

2 years ago
Just to make it clear - Windows 7 Enterprise X64, with all updates. The issue persisted even before I did WUpdate last month (Windows was not updated for about a year then).

Comment 2

2 years ago
Please post your crash IDs here per

Does your crashing stop if you have started Thunderbird in safe mode per
Severity: normal → critical
Keywords: crash

Comment 3

2 years ago
I'm posting my last crash IDs, since I've reinstalled (cleanly) two times since the crashes started, and I lost my previous data. This is from 38.4.0 (clean install a month ago, for a test) updated later to 38.5.1, and finally to 38.6.0.


I didn't test Safe Mode, it is my working email client and cannot afford to wait for 2 or 3 days for this to happen. As I mentioned, it didn't crash at least for almost 6 days when I had no other folders selected for auto-check (in addtition to the default Inbox). Now (3 days ago during my last TB restart) I had selected just one additional folder in one of the accounts, and 3 days later it crashed at a moment when this same account was scheduled to auto-check.

Comment 4

2 years ago
signatures are all over the place.  So likely causes are antivirus, corruption or variation of bug 1133892 	
 nsGetInterface::operator()  bp-2d4631a9-4b61-468d-bf88-732d22160228
 msvcr120.dll@0xf189 | nsTArray_CopyWithMemutils::MoveElements  bp-a947206c-2d49-41fb-ab81-eed132160219
 nsInterfaceRequestorAgg::GetInterface  bp-c6d783b8-73e5-4631-95ce-564be2160210 (but doesn't have mozilla::psm::TransportSecurityInfo::GetInterface  on the stack)
 ShouldMarkCrossCompartment  bp-c7d71fb0-3d3a-406d-bc24-5a8a72160207

Why is it that you need to enable "When getting new message for this account, always check this folder"?
Do you crash only when there is no mail in these folders?
Do you have filters operating against any of these folders (as a source folder or a target folder)?
Depends on: 1133892
Flags: needinfo?(teohad)

Comment 5

2 years ago
I have no antivirus (never did), no third party system tools like firewalls (using the built-in one).
I had absolutely no problems with TB until 2 months ago when I decided to transfer my 3 pop accounts to IMAP (all gmail). TB regularly sustained 2-3 months of uptime for years, as many other programs do (FF including). It all started 2 months ago when I redefined my pop accounts to imap.

As to getting new messages in other folders - I have server-side filters that move certain emails to these folders skipping the Inbox. I need notifications for them as well as for the Inbox. For what it's worth now, after 2 months of hunting the cause, this option (activated for at least one folder) seems the culprit. The one and only time TB sustained 6 days with no crash was when I disabled this option for all folders (only Inbox being auto-checked by default).
I had filters in previous installation, but after the clean reinstalls I had absolutely virgin TB with no filters etc., still crashes after at most 3 days when there is some folder selected to auto-check (the When getting new mail always check.... option).

"Do you crash only when there is no mail in these folders?"
- it absolutely does not matter, sometimes there is new mail in the morning when I see the crash reporter (I see the new mail tray icon left over), sometimes it crashes just 2-3 hours after start, with no new mail (read or unread) received.

Now I disabled server-side filters and will collect all mail in Inbox, and will set up rules to somehow automatically move mail to other folders periodically. TB filters alone are not reliable as they do not apply for mail that has been read on another device before TB had the chance to download it, which is a known bug.
I'll leave it like that from now on (can do months of uptime), to be even more confident it was indeed the cause (if it wouldn't crash).
As I see it, there is some race condition with this option enabled for even a single folder, and although I got used to it, I'll try to live without it and just use local filters to move mail around.
Flags: needinfo?(teohad)

Comment 6

2 years ago
Thanks for the info.  I incorrectly worded "Do you crash only when there is no mail in these folders?". What I meant is
 Do you crash only when there is new mail in these folders?
Ever confirmed: true
Flags: needinfo?(teohad)

Comment 7

2 years ago
No. As I wrote before, there is no pattern in it. Sometimes TB crashes 2-3 hours after being started (2 or 3 scheduled checks in total, two accounts set up to check every 60 minutes) with no email received anywhere, other times it can stay in background for day or two before crashing, meanwhile receiving low volume emails. I don't receive or write lot of messages, on average 5-6 per day.
It crashes when there is no email in these "selected" folders, I even dare say it might not as well have been any. Those folders are even lower volume'd.
Once it crashed during new mail composition (and I lost the text) - I guess it was in a scheduled-check moment.
Flags: needinfo?(teohad)

Comment 8

2 years ago
Now 7 days after the last start (all additional IMAP folders still unselected for "When getting new messages for this account, always check this folder"), I confirm Thunderbird is still up and running flawlessly (no crash). The two accounts that are scheduled for autocheck are still every 30 and 40 minutes respectively.
I'm 99.9% confident that is the culprit. Two times I managed to keep it crash-free for more than 3-4 days, and both were setup with no additional folders to auto-check.
I hope this would be helpful.

Meanwhile I'm hoping for a successful resolution of the other long-term bug with TB's filters not being fired when messages are already read on another device before TB sees them.


2 years ago
Crash Signature: [@ nsGetInterface::operator() ] [@ msvcr120.dll@0xf189 | nsTArray_CopyWithMemutils::MoveElements ] [@ nsInterfaceRequestorAgg::GetInterface ] [@ ShouldMarkCrossCompartment ]
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
Summary: Thunderbird crashes regularly when autochecking additional IMAP folders → Thunderbird crashes regularly when autochecking additional IMAP folders that get mail from server-side filters
Version: 38 Branch → 38

Comment 9

2 years ago
Thanks for taking my report seriously.
It's almost 12 days since the last start, TB is still up and running with the same setup. I can add another nine in the percentage above that denotes my confidence what causes the crash.
Now I won't write again unless it crashes at a moment of autocheck or I have other details to add.
Maybe all this has something to do with GMail's implementation of folders or something. I have only GMail accounts but I can add my Yahoo one in TB at some point to test with it alone.
WFM per previous comments. If I have misundrstood and you are still seeing the problem please update the but report
Last Resolved: a year ago
Resolution: --- → WORKSFORME

Comment 11

a year ago
Please reopen, just happend with 52.2.0

Comment 12

a year ago
(In reply to Petr Vones from comment #11)
> Please reopen, just happend with 52.2.0

I see, the automatically assigned bug by the signature ShouldMarkCrossCompartment is probably incorrect and unrelated to this issue.
You need to log in before you can comment on or make changes to this bug.