+++ This bug was initially created as a clone of (FIXED in TB31) Bug #991626 +++ NS_CycleCollectorSuspect3 #10 crash for Thunderbird 31.4.0 #4 crash for Thunderbird 38.0a1 nsXPCWrappedJS::Release() #24 crash for Thunderbird 31.4.0 #5 crash for Thunderbird 38.0a1 As it happens, I've crashed several times recently (laptop) with both NS_CycleCollectorSuspect3 and nsXPCWrappedJS::Release(). Do they have the same root cause? Or do we need two bugs? NS_CycleCollectorSuspect3 bp-41e5c719-60cc-4eb9-b463-baee52150207 via nsMsgComposeAndSend::~nsMsgComposeAndSend() 0 xul.dll NS_CycleCollectorSuspect3 xpcom/base/nsCycleCollector.cpp 1 xul.dll nsGlobalWindow::Release() dom/base/nsGlobalWindow.cpp 2 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/compose/src/nsMsgSend.cpp:323 3 xul.dll nsMsgComposeAndSend::`scalar deleting destructor'(unsigned int) 4 xul.dll nsMsgComposeAndSend::Release() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/compose/src/nsMsgSend.cpp:255 5 xul.dll CopyListener::~CopyListener() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/compose/src/nsMsgCopy.cpp:49 6 xul.dll CopyListener::`scalar deleting destructor'(unsigned int) 7 xul.dll mozilla::net::FileOpenHelper::Release() netwerk/cache2/CacheFile.cpp nsXPCWrappedJS::Release() bp-a3da1435-0f95-46de-862c-5dcd62150208 via nsMsgProgress::~nsMsgProgress() bp-af5122c1-2355-4568-b296-b47b32150211 via nsMsgProgress::~nsMsgProgress() 0 xul.dll nsXPCWrappedJS::Release() js/xpconnect/src/XPCWrappedJS.cpp 1 xul.dll nsXPTCStubBase::Release() xpcom/reflect/xptcall/xptcall.cpp 2 xul.dll ReleaseObjects xpcom/glue/nsCOMArray.cpp 3 xul.dll nsCOMArray_base::Clear() xpcom/glue/nsCOMArray.cpp 4 xul.dll nsMsgProgress::~nsMsgProgress() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/base/src/nsMsgProgress.cpp:34 5 xul.dll nsMsgProgress::`scalar deleting destructor'(unsigned int) 6 xul.dll nsMsgProgress::Release() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/base/src/nsMsgProgress.cpp:21 7 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/compose/src/nsMsgSend.cpp:323 8 xul.dll nsMsgComposeAndSend::`scalar deleting destructor'(unsigned int) 9 xul.dll nsMsgComposeAndSend::Release() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/compose/src/nsMsgSend.cpp:255 10 xul.dll CopyListener::~CopyListener() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/compose/src/nsMsgCopy.cpp:49 11 xul.dll CopyListener::`scalar deleting destructor'(unsigned int) 12 xul.dll mozilla::net::FileOpenHelper::Release() netwerk/cache2/CacheFile.cpp 13 xul.dll nsImapMailCopyState::~nsImapMailCopyState() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/imap/src/nsImapMailFolder.cpp:8215 14 xul.dll nsImapMailCopyState::`scalar deleting destructor'(unsigned int) 15 xul.dll mozilla::net::WebSocketRequest::Release() netwerk/base/Dashboard.cpp 16 xul.dll nsImapUrl::~nsImapUrl() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/imap/src/nsImapUrl.cpp:79 17 xul.dll nsImapUrl::`scalar deleting destructor'(unsigned int) 18 xul.dll nsMsgMailNewsUrl::Release() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/base/util/nsMsgMailNewsUrl.cpp:57 19 xul.dll nsSmtpUrl::Release() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/compose/src/nsSmtpUrl.cpp:599 20 xul.dll nsMsgProtocol::~nsMsgProtocol() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/base/util/nsMsgProtocol.cpp:83 21 xul.dll nsImapProtocol::~nsImapProtocol() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/imap/src/nsImapProtocol.cpp:581 22 xul.dll nsImapProtocol::`scalar deleting destructor'(unsigned int) 23 xul.dll nsBaseAppShell::Release() widget/nsBaseAppShell.cpp 24 xul.dll nsImapProtocol::Release() c:/builds/moz2_slave/tb-c-cen-w32-ntly-000000000000/build/mailnews/imap/src/nsImapProtocol.cpp:291 perhaps unrelated bp-8cee1d98-3fda-4e77-9e49-1000c2150206 @ js::ShapeTable::search(jsid, bool)

Yeah, those look like the same issue. Something off the main thread is releasing a main-thread-only object, which either dies in nsXPCWrappedJS::Release(), which hard codes a check if we're off the main thread and crashes, or in NS_CycleCollectorSuspect3, because we attempt to retrieve a pointer to the current thread's cycle collector, but there isn't one on the thread, so we crash in a null pointer deref. Whatever it is that is releasing the mainthread object needs to dispatch it to the main thread to be released there, or something.

I wonder if this could be the same base issue as bug 1125672, and fixed by the patch there? If the smtp url got stored in m_url, then it would be at risk of releasing off main thread. We should see if these crashes occur after that bug landed on 2015-02-05

Yeah, that looks very similar.

Kent, your work in bug 1125672 is paying off big time. NS_CycleCollectorSuspect3 results are very encouraging. zero crashes for builds Builds after 2015-02-05 https://crash-stats.mozilla.com/report/list?signature=NS_CycleCollectorSuspect3&product=Thunderbird&query_type=contains&range_unit=days&process_type=any&version=Thunderbird%3A38.0a1&hang_type=any&date=2015-02-12+11%3A00%3A00&range_value=14#tab-reports nsXPCWrappedJS::Release results are also encouraging - for 2 week period there are 35 crashes before 2015-02-06, and only 2 crashes [1] thereafter. The stacks of [1] match Bug 1044443, so it's all covered. https://crash-stats.mozilla.com/report/list?signature=nsXPCWrappedJS%3A%3ARelease%28%29&product=Thunderbird&query_type=contains&range_unit=days&process_type=any&version=Thunderbird%3A38.0a1&hang_type=any&date=2015-02-12+11%3A00%3A00&range_value=14#tab-reports So we can declare this fixed by bug 1125672. It's baked for a week and I'm not seeing new signature or problem reports. So we should consider pushing it's patch into other branches - 37, (I guess too late for 36), and ESR 31. [1] remaining nsXPCWrappedJS::Release() crashes bp-20a0e4aa-5dc5-4c24-8701-d5ee12150209 bp-e9de7244-0fb5-41c1-a7aa-486532150210

Looking at crashes with this signature, many do indeed look very similar to those from bug 1125672. But that was fixing a sudden increase in crashes due to a regression that landed in TB 38, while this signature has existed for awhile (like https://crash-stats.mozilla.com/report/index/98f42f49-c581-47b6-b5d3-fe0022150205 which is TB 31.4.0) So I think we need to treat this as a separate bug that still needs addressing.

(In reply to Kent James (:rkent) from comment #5) > Looking at crashes with this signature, many do indeed look very similar to > those from bug 1125672. But that was fixing a sudden increase in crashes due > to a regression that landed in TB 38, while this signature has existed for > awhile (like > https://crash-stats.mozilla.com/report/index/98f42f49-c581-47b6-b5d3- > fe0022150205 which is TB 31.4.0) > > So I think we need to treat this as a separate bug that still needs > addressing. Quite right - I am conflating two crashes. I'll use this one for the Thunderbird 38 crash. NS_CycleCollectorSuspect3 #4 crash for Thunderbird 38.0a1 nsXPCWrappedJS::Release() #5 crash for Thunderbird 38.0a1 And file a new bug for crashes in prior versions