Closed Bug 610472 Opened 14 years ago Closed 5 years ago

crash [@ nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState*)] - null mDatabase

Categories

(MailNews Core :: Networking: IMAP, defect)

x86
All
defect
Not set
critical

Tracking

(thunderbird_esr60 affected, thunderbird64 affected)

RESOLVED INCOMPLETE
Tracking Status
thunderbird_esr60 --- affected
thunderbird64 --- affected

People

(Reporter: wsmwk, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [rare])

Crash Data

crash [@ nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState*)]

bp-9e0f944c-04d1-48f7-8524-0820a2101105 v3.1.6 "I don't know what happened... I left it open while using another app and it crashed."
0	thunderbird.exe	nsImapMailFolder::SyncFlags	mailnews/imap/src/nsImapMailFolder.cpp:4721
1	thunderbird.exe	nsImapMailFolder::UpdateImapMailboxInfo	mailnews/imap/src/nsImapMailFolder.cpp:2879
2	xpcom_core.dll	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
3	xpcom_core.dll	nsProxyObjectCallInfo::Run	xpcom/proxy/src/nsProxyEvent.cpp:181
4	xpcom_core.dll	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:527 

bp-95fb0efb-6bee-4aeb-8bcd-7c70b2101105 (mnaltd) aol user who, it seems can't start TB on their Macs
0	thunderbird-bin	nsImapMailFolder::SyncFlags	mailnews/imap/src/nsImapMailFolder.cpp:4728
1	thunderbird-bin	nsImapMailFolder::UpdateImapMailboxInfo	mailnews/imap/src/nsImapMailFolder.cpp:2879
2	libxpcom_core.dylib	libxpcom_core.dylib@0x6e120	
3	libxpcom_core.dylib	nsProxyObjectCallInfo::Run	xpcom/proxy/src/nsProxyEvent.cpp:181
4	libxpcom_core.dylib	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:527
5	libxpcom_core.dylib	NS_ProcessPendingEvents_P	nsThreadUtils.cpp:200
crashes are 
EXCEPTION_ACCESS_VIOLATION_READ
0x0
the lines below are based on comm-central instead of comm-1.9.2.

so nsImapMailFolder is in theory threaded, which means this whole thing seems likely to be a disaster

2690 NS_IMETHODIMP nsImapMailFolder::UpdateImapMailboxInfo(nsIImapProtocol* aProtocol, nsIMailboxSpec* aSpec)
2691 {
so, we call SyncFlags:
2880   SyncFlags(flagState);
and then we check to see if mDatabase is non null.
2881   if (mDatabase && mNumUnreadMessages + keysToFetch.Length() > numUnreadFromServer)

4740 nsresult nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState *flagState)
4741 {
4742   nsresult rv = GetDatabase(); // we need a database for this
4743   NS_ENSURE_SUCCESS(rv, rv);

here we think we might have a database.

4745   flagState->GetPartialUIDFetch(&partialUIDFetch);
4755   flagState->GetNumberOfMessages(&messageIndex);
4758   flagState->GetSupportedUserFlags(&supportedUserFlags);

4760   for (PRInt32 flagIndex = 0; flagIndex < messageIndex; flagIndex++)
4761   {
4763     flagState->GetUidOfMessage(flagIndex, &uidOfMessage);
4765     flagState->GetMessageFlags(flagIndex, &flags);

here we crash (because we don't have a database):
4768     rv = mDatabase->ContainsKey(uidOfMessage , &containsKey);

4774     rv = mDatabase->GetMsgHdrForKey(uidOfMessage, getter_AddRefs(dbHdr));
4775     if (NS_SUCCEEDED(dbHdr->GetMessageSize(&messageSize)))
4779     if (NS_SUCCEEDED(flagState->GetCustomFlags(uidOfMessage, getter_Copies(keywords))))
4780         HandleCustomFlags(uidOfMessage, dbHdr, supportedUserFlags, keywords);
4781 
4782     NotifyMessageFlagsFromHdr(dbHdr, uidOfMessage, flags);
4783   }
Summary: crash [@ nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState*)] → crash [@ nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState*)] - null mDatabase
(In reply to comment #2)

> so nsImapMailFolder is in theory threaded, which means this whole thing seems
> likely to be a disaster

It's not threaded at all - the methods are only called from the UI thread. we use synchronous xpcom proxies to proxy calls from the imap threads to the ui thread.
Crash Signature: [@ nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState*)]
(In reply to timeless from comment #2)
> 4760   for (PRInt32 flagIndex = 0; flagIndex < messageIndex; flagIndex++)
> 4761   {
> 4763     flagState->GetUidOfMessage(flagIndex, &uidOfMessage);
> 4765     flagState->GetMessageFlags(flagIndex, &flags);
> 
> here we crash (because we don't have a database):
> 4768     rv = mDatabase->ContainsKey(uidOfMessage , &containsKey);
> 
> 4774     rv = mDatabase->GetMsgHdrForKey(uidOfMessage,
> getter_AddRefs(dbHdr));

(A) Because preemptive multi-tasking is ordinal nowadays, execution of above code can be interrupted and halted after 4765, and OS gets control at the CPU.
(B) Because multi CPU environment is popular nowadays, different task can run concurrently. The different task can be other Job of Tb.

David, can "timer pop MsgDB close" run and close DB while IMAP task of (A) is halted at 4765?
Crash Signature: [@ nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState*)] → [@ nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState*)] [@ nsImapMailFolder::SyncFlags]
Blocks: 1312254
Still a consistent crash. And probably related to one of the other imap crashes :(

Examples

bp-5dac3d97-0537-4902-9cfe-918440181111 60.0b2?

bp-2f8437da-a867-4cab-9b60-473970181123 60.3.0
 0 	xul.dll	nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState*)	comm/mailnews/imap/src/nsImapMailFolder.cpp:4850
1 	xul.dll	nsImapMailFolder::UpdateImapMailboxInfo(nsIImapProtocol*, nsIMailboxSpec*)	comm/mailnews/imap/src/nsImapMailFolder.cpp:2820
2 	xul.dll	`anonymous namespace'::SyncRunnable2<nsIImapProtocolSink, nsIMsgMailNewsUrl*, nsIMsgWindow**>::Run	comm/mailnews/imap/src/nsSyncRunnableHelpers.cpp:147
3 	xul.dll	nsThread::ProcessNextEvent(bool, bool*)	xpcom/threads/nsThread.cpp:1040
4 	ntdll.dll	RtlAcquireSRWLockExclusive	
5 	xul.dll	NS_ProcessNextEvent(nsIThread*, bool)	xpcom/threads/nsThreadUtils.cpp:517 

bp-7d22f22a-759b-4c98-b06e-0affa0180604 52.8.0 user marked 60k messages unread
 0 	xul.dll	nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState*)	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/imap/src/nsImapMailFolder.cpp:4869
1 	xul.dll	nsImapMailFolder::UpdateImapMailboxInfo(nsIImapProtocol*, nsIMailboxSpec*)	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/imap/src/nsImapMailFolder.cpp:2840
2 	xul.dll	`anonymous namespace'::SyncRunnable2<nsIImapMailFolderSink, nsIImapProtocol*, nsIImapHeaderXferInfo*>::Run	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/imap/src/nsSyncRunnableHelpers.cpp:146
3 	xul.dll	nsThread::ProcessNextEvent(bool, bool*)	xpcom/threads/nsThread.cpp:1216 

bp-0a11fe02-608f-4d32-acd2-a48e80181020 52.9.1
 0 	xul.dll	nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState*)	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/imap/src/nsImapMailFolder.cpp:4867
1 	xul.dll	nsImapMailFolder::UpdateImapMailboxInfo(nsIImapProtocol*, nsIMailboxSpec*)	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/imap/src/nsImapMailFolder.cpp:2838
2 	xul.dll	`anonymous namespace'::SyncRunnable2<nsIImapMailFolderSink, nsIImapProtocol*, nsIImapHeaderXferInfo*>::Run	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/imap/src/nsSyncRunnableHelpers.cpp:146
3 	xul.dll	nsThread::ProcessNextEvent(bool, bool*)	xpcom/threads/nsThread.cpp:1216
Crash Signature: [@ nsImapMailFolder::SyncFlags(nsIImapFlagAndUidState*)] [@ nsImapMailFolder::SyncFlags] → [@ nsImapMailFolder::SyncFlags]
Whiteboard: [dupeme?]
See Also: → 871622

Note, issues related to not having database may have been fixed in Bug 1312254 - Crash in nsImapMailFolder::NotifyMessageFlagsFromHdr

The current crash rate is quite low, ~6 per day for version 60.* L

Whiteboard: [dupeme?] → [closeme 2019-08-01][dupeme?][rare]

version 68 not out yet, so extending date

Whiteboard: [closeme 2019-08-01][dupeme?][rare] → [closeme 2019-10-01][dupeme?][rare]

Almost non-existent signature for version 68. So if this problem still exists the signature has changed

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2019-10-01][dupeme?][rare] → [rare]
You need to log in before you can comment on or make changes to this bug.