Crash in [@ NS_CycleCollectorSuspect3 | IdleRequestExecutor::Release] via via nsMsgComposeAndSend::~nsMsgComposeAndSend
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(thunderbird_esr91 unaffected)
Tracking | Status | |
---|---|---|
thunderbird_esr91 | --- | unaffected |
People
(Reporter: mccr8, Unassigned)
References
Details
(Keywords: crash, topcrash-thunderbird, Whiteboard: [fixed by smtp-js bug 1661694])
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/5484586d-8ac6-4929-a7a5-79a830210422
Reason: EXCEPTION_ACCESS_VIOLATION_READ
Top 10 frames of crashing thread:
0 xul.dll NS_CycleCollectorSuspect3 xpcom/base/nsCycleCollector.cpp:3759
1 xul.dll IdleRequestExecutor::Release dom/base/nsGlobalWindowInner.cpp:497
2 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend comm/mailnews/compose/src/nsMsgSend.cpp:304
3 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend comm/mailnews/compose/src/nsMsgSend.cpp:283
4 xul.dll nsMsgComposeAndSend::Release comm/mailnews/compose/src/nsMsgSend.cpp:244
5 xul.dll CopyListener::~CopyListener comm/mailnews/compose/src/nsMsgCopy.cpp:41
6 xul.dll ArrayBufferInputStream::Release netwerk/base/BackgroundFileSaver.cpp:1077
7 xul.dll nsImapMailCopyState::~nsImapMailCopyState comm/mailnews/imap/src/nsImapMailFolder.cpp:7611
8 xul.dll nsImapMailCopyState::~nsImapMailCopyState comm/mailnews/imap/src/nsImapMailFolder.cpp:7608
9 xul.dll mozilla::dom::`anonymous namespace'::FileCreationHandler::Release dom/base/BodyConsumer.cpp:436
Similar to bug 1707004, this is being caused by a cycle collected object getting destroyed off the main threaad.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 1•3 years ago
•
|
||
One of this bugs is the following.
https://searchfox.org/comm-central/rev/7dc9ab8a012750252902a311da4e0244285c39b8/mailnews/imap/src/nsImapProtocol.cpp#1150-1160
NS_IMETHODIMP nsImapProtocol::Run() {
..
// shutdown this thread, but do it from the main thread
nsCOMPtr<nsIRunnable> ev = new nsImapThreadShutdownEvent(m_iThread);
if (NS_FAILED(NS_DispatchToMainThread(ev)))
NS_WARNING("Failed to dispatch nsImapThreadShutdownEvent");
m_iThread = nullptr;
// Release protocol object on the main thread to avoid destruction of 'this'
// on the IMAP thread, which causes grief for weak references.
nsCOMPtr<nsIImapProtocol> releaseOnMain(this);
NS_ReleaseOnMainThread("nsImapProtocol::this", releaseOnMain.forget());
return NS_OK;
I guess this is race condition between main thread and IMAP thread.
IMAP thread is running Runnable
by nsImapProtocol
. But it is possible to run releaseOnMain
for nsIImapProtocol
before decrementting reference count of Runnable
by nsImapProtocol
on IMAP thread. So then the destructor of nsImapProtocol
may run on IMAP thread that is shutting down.
So I think that nsImapThreadShutdownEvent
should be dispatched to IMAP thread, not main thread, then it should dispatch other new Runnable
to main thread for shutdown. nsImapThreadShutdownEvent
and nsIImapProtocol->Release()
shouldn't run until nsImapProtocol::Run
is finished.
Updated•3 years ago
|
Comment 2•3 years ago
|
||
This is surely not a Windows only issue. A couple candidates for Mac
- NS_CycleCollectorSuspect3 | <name omitted> | nsMsgComposeAndSend::~nsMsgComposeAndSend bp-21232eda-d4dd-46ab-8992-9cbac0210729
- NS_CycleCollectorSuspect3 | nsArrayCC::Release bp-c650522d-a9d5-4cc0-b5f4-368db0210731
Comment 3•3 years ago
|
||
This is fixed by smtp-js bug 1661694. See bug 1517464 comment 69 for details
Updated•3 years ago
|
Description
•