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?]

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.