Closed Bug 1707006 Opened 4 years ago Closed 3 years ago

Crash in [@ NS_CycleCollectorSuspect3 | IdleRequestExecutor::Release] via via nsMsgComposeAndSend::~nsMsgComposeAndSend

Categories

(MailNews Core :: Networking: IMAP, defect)

x86
Windows 7
defect

Tracking

(thunderbird_esr91 unaffected)

RESOLVED FIXED
88 Branch
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.

See Also: → 1707007
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core

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.

Flags: needinfo?(benc)

This is surely not a Windows only issue. A couple candidates for Mac

Severity: -- → S2
Depends on: 1175168
See Also: → 1517464

This is fixed by smtp-js bug 1661694. See bug 1517464 comment 69 for details

Status: NEW → RESOLVED
Closed: 3 years ago
Depends on: smtp-js
Flags: needinfo?(benc)
Resolution: --- → FIXED
Summary: Crash in [@ NS_CycleCollectorSuspect3 | IdleRequestExecutor::Release] → Crash in [@ NS_CycleCollectorSuspect3 | IdleRequestExecutor::Release] via via nsMsgComposeAndSend::~nsMsgComposeAndSend
Whiteboard: [fixed by smtp-js bug 1661694]
Target Milestone: --- → 88 Branch
Depends on: 1742991
You need to log in before you can comment on or make changes to this bug.