471678 - Mac shutdown crash [@ nsParseMailMessageState::Release]

Status: RESOLVED DUPLICATE of bug 464419

(Thunderbird :: General, defect)

Description

[Wayne Mery (:wsmwk)]

Mac shutdown crash [@ nsParseMailMessageState::Release]
topcrash for trunk

some frames are missing source references

"just pressed cmd-q on mac os (exit program)"
bp-ad03ca9a-d8b1-42c8-9b56-172bc2081230
libxpcom_core.dylib@0x3329	
thunderbird-bin@0x1b649f	
nsParseMailMessageState::Release	nsParseMailbox.cpp:508
libxpcom_core.dylib@0x332b	
thunderbird-bin@0x17c47a	
nsRDFResource::Release	nsRDFResource.cpp:78
nsCOMPtr_base::assign_with_AddRef	xpcom/glue/nsCOMPtr.h:456
nsMsgDatabase::CleanupCache	nsCOMPtr.h:640
nsGenericModule::Release	nsGenericFactory.cpp:245
nsCOMPtr_base::assign_with_AddRef	xpcom/glue/nsCOMPtr.h:456
info_ClearEntry	nsCOMPtr.h:640
PL_DHashTableFinish	pldhash.c:383
nsComponentManagerImpl::Shutdown	xpcom/components/nsStaticComponentLoader.h:70
NS_ShutdownXPCOM_P	xpcom/build/nsXPComInit.cpp:843
ScopedXPCOMStartup::RegisterProfileService	toolkit/xre/nsAppRunner.cpp:948
XRE_main	toolkit/xre/nsAppRunner.cpp:3306
main	nsMailApp.cpp:103
thunderbird-bin@0x1c05	
thunderbird-bin@0x1b2c	
@0x2	

slightly stranger stack
bp-c190219f-cc62-4479-bca3-d01e82081229
libxpcom_core.dylib@0x3329	
thunderbird-bin@0x1b6b47	
nsParseMailMessageState::Release	nsParseMailbox.cpp:508
libxpcom_core.dylib@0x332b	
thunderbird-bin@0x17cb22	
nsRDFResource::Release	nsRDFResource.cpp:78
libxpcom_core.dylib@0x332b	
thunderbird-bin@0x531344	
thunderbird-bin@0x1da367	
nsMsgDBView::Release	nsMsgDBView.cpp:136
libxpcom_core.dylib@0x332b	
nsMsgDatabase::NotifyAnnouncerGoingAway	nsCOMPtr.h:469
nsMsgDatabase::ForceClosed	nsMsgDatabase.cpp:1218
nsMsgDatabase::CleanupCache	nsMsgDatabase.cpp:737
nsGenericModule::Release	nsGenericFactory.cpp:245
nsCOMPtr_base::assign_with_AddRef	xpcom/glue/nsCOMPtr.h:456
info_ClearEntry	nsCOMPtr.h:640
PL_DHashTableFinish	pldhash.c:383
nsComponentManagerImpl::Shutdown	xpcom/components/nsStaticComponentLoader.h:70
NS_ShutdownXPCOM_P	xpcom/build/nsXPComInit.cpp:843
ScopedXPCOMStartup::RegisterProfileService	toolkit/xre/nsAppRunner.cpp:948

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Attachment: my exciting backtrace

The failure is NSCAP_LOG_RELEASE(this, mRawPtr) on m_backupMailDB.
mRawPtr has a valid value, 0x7ff234731ce0, but when we go look there, we see:
(gdb) p *aObject
$9 = {_vptr.nsISupports = 0x5a5a5a5a5a5a5a5a}

This accordingly explodes in the attempt to perform a dynamic cast.

Interesting-like, the ImapFolder who is the owner of the nsMsgMailboxParser's mBackupDatabase is null.  After a brief perusal, the thing that jumps out at me is that nsImapMailFolder::SetupHeaderParseStream sets it iff mBackupDatabase, so it (nsImapMailFolder) will never null it out at that call site.  nsImapMailFolder does not implement logic in its RemoveBackupMsgDatabase to do anything about clearing it itself, and has a code path that calls that method.  Things get confusing after that though, as the header parser may call RemoveBackupMsgDatabase itself (and clear its m_backupMailDB).

m_downloadMessageForOfflineUse = 1, btw.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Since this involves message database parsing, that code involves a tangled web, and both bienvenu and rkent crawl it daily, I figure they are best suited to fix the immediate crash and any fundamental underlying issues.  (if rkent has not already done so with his recent work; my build is a few days old at least...)

Comment 3

[Kent James (:rkent)]

nsMsgDatabase::CleanupCache is evil. It has the infamous delete pMessageDB, and is the source of my shutdown crashes with js db listeners in bug 471071 - which I only "fix" by convincing everything to close before they can be "cleaned" by this routine.

I assume that the issue is that the m_backupDatabase object has been deleted prior to its being used again in ~nsParseMailMessageState, and the likely point of deletion is the delete pMessageDB in CleanupCache() which does not follow XPCOM rules. One possibility is to try to fix that delete, for example changing "if (refcount != 0)" to "if (refcount == 1)" here (http://mxr.mozilla.org/comm-central/source/mailnews/db/msgdb/src/nsMsgDatabase.cpp#742):

       if (refcount != 0)
        {
          // The destructor may cause the remaining references to be
          // released, so stabilize the refcount and then manually
          // delete.
          ++pMessageDB->mRefCnt;
          delete pMessageDB;
        }

This bug BTW is a dup of Bug 464419.