1852017 - Crash in [@ mozilla::net::LoadInfo::~LoadInfo] - nsImapProtocol::~nsImapProtocol called on Socket Thread. Going offline or online.

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[Wayne Mery (:wsmwk)]

Crash report: https://crash-stats.mozilla.org/report/index/a05de7d2-44ff-4c70-9125-99e2b0230815 "a very long email which I constantly saved as a draft" according to reporter

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(NS_IsMainThread())

Top 10 frames of crashing thread:

0  xul.dll  mozilla::net::LoadInfo::~LoadInfo  netwerk/base/LoadInfo.cpp:823
1  xul.dll  mozilla::net::LoadInfo::Release  netwerk/base/LoadInfo.cpp:821
2  xul.dll  nsCOMPtr<nsILoadInfo>::~nsCOMPtr  xpcom/base/nsCOMPtr.h:340
2  xul.dll  nsMsgProtocol::~nsMsgProtocol  mailnews/base/src/nsMsgProtocol.cpp:91
3  xul.dll  nsImapProtocol::~nsImapProtocol  mailnews/imap/src/nsImapProtocol.cpp:718
4  xul.dll  nsImapProtocol::`vector deleting destructor'  
5  xul.dll  nsHashPropertyBag::Release  xpcom/ds/nsHashPropertyBag.cpp:290
6  xul.dll  nsMsgProtocol::Release  mailnews/base/src/nsMsgProtocol.cpp:51
7  xul.dll  nsImapProtocol::Release  
8  xul.dll  nsCOMPtr<nsIInputStreamCallback>::~nsCOMPtr  xpcom/base/nsCOMPtr.h:340

Comment 1

[Magnus Melin [:mkmelin]]

Updating the summary, but I don't know how to fix.

Comment 2

[Wayne Mery (:wsmwk)]

Attachment: graph of crash counts

Looking at the stats, with version 115 there is a definite increase in crash rate for both Firefox and Thunderbird...

Comment 3

[Wayne Mery (:wsmwk)]

... so there must be some form of regression.

Comment 4

[Wayne Mery (:wsmwk)]

Ideas?

bp-d733c3b6-cba4-4cc4-b30a-a90c30231026 "It went out yesterday, too while trying to put a message in "Sent."
Bp-ad8a648a-5389-449d-81a1-c8aca0231027
Bp-b2248c0f-d9b1-4ba3-982f-757e10230927 "crash before / after hibernation"

Comment 5

[Makoto Kato [:m_kato] (fever, slow response)]

I doesn't know, but I guess that

• Server will use RFC 4978 (IMAP Compress mode)
• This occurs after IMAP thread shuts down (network is offline).

https://searchfox.org/comm-central/rev/d9d660e0e3452440b74be99b154f90e7f6417483/mailnews/imap/src/nsImapProtocol.cpp#1627 will call NS_NewInputStreamReadyEvent finally, then nsImapProtocol::Release is called on socket thread.

I think that we can fix this if nsImapProtocol doesn't have nsIInputStreamCallback. We should use wrapper class for it instead.

Comment 6

[Wayne Mery (:wsmwk)]

Ben, is comment 5 (wrapper class or some other change) already encompassed in work you are already doing?

And FWIW, no v102 crashes are found but didn't state that in comment 2.
IF there are no v102 crashes and if this is a regression, then attempting to find a c-c change that caused this:

• only three imap fixes in the 6 months prior to shipping 115 https://mzl.la/4bBdgmL
• of bugs fixed in 2022 and not uplifted to 102, the most wide ranging is Bug 1801067 - Port bug 1791633: separate TLS socket control from transport security info - comm/mailnews/imap/test/unit/test_starttlsFailure.js failing on debug
• bp-58b67346-7ee5-4a00-9966-9bcec0231206 115.0b6 is the oldest we can find on crash-stats today

Other examples:

• bp-1fc554a7-1d8a-4ed4-8fee-4c12c0231129 user going offline
• bp-bd382056-938b-4c54-aba3-ff86c0231123 user clicked offline, clicked online and moved some mail, then clicked offline again

Comment 7

[Petr Sumbera]

We have seen the crash on Solaris i386 with TB 115.11.0:

thunderbird:core> ::stack
libc.so.1`__lwp_sigqueue+0xa()
libc.so.1`raise+0x1c()
libxul.so`nsProfileLock::FatalSignalHandler+0xdd()
libxul.so`WasmTrapHandler+0xf0()
libc.so.1`__sighndlr+6()
libc.so.1`call_user_handler+0x3cb()
libc.so.1`sigacthandler+0x155((int) 11, (siginfo_t *) 0x7fb604d9d460, (void *) 0x7fb604d9c670)
libxul.so`mozilla::net::LoadInfo::~LoadInfo+0x28e()
libxul.so`mozilla::net::LoadInfo::Release+0x25()
libxul.so`nsMsgProtocol::~nsMsgProtocol+0x72()
libxul.so`nsImapProtocol::~nsImapProtocol+0x403()
libxul.so`nsImapProtocol::~nsImapProtocol+0x11()
libxul.so`nsHashPropertyBag::Release+0x2c()
libxul.so`nsMsgProtocol::Release+0xd()
libxul.so`nsImapProtocol::Release+0xd()
libxul.so`already_AddRefed<mozilla::CancelableRunnable> NS_NewCancelableRunnableFunction<CallbackHolder::CallbackHolder+0x49()
libxul.so`mozilla::Runnable::Release+0x29()
libxul.so`mozilla::DiscardableRunnable::Release+9()
libxul.so`mozilla::CancelableRunnable::Release+9()
libxul.so`already_AddRefed<mozilla::CancelableRunnable> NS_NewCancelableRunnableFunction<CallbackHolder::CallbackHolder+9()
libxul.so`nsPipeEvents::~nsPipeEvents+0x4e()
libxul.so`nsPipe::OnPipeException+0x1cf()
libxul.so`nsPipeOutputStream::CloseWithStatus+0x43()
libxul.so`nsAStreamCopier::Process+0x2a0()
libxul.so`non-virtual thunk to nsAStreamCopier::Run+0x17()
libxul.so`nsThread::ProcessNextEvent+0x371()
libxul.so`NS_ProcessNextEvent+0x30()
libxul.so`mozilla::net::nsSocketTransportService::Run+0x44c()
libxul.so`nsThread::ProcessNextEvent+0x371()
libxul.so`NS_ProcessNextEvent+0x30()
libxul.so`mozilla::ipc::MessagePumpForNonMainThreads::Run+0x114()
libxul.so`MessageLoop::RunInternal+0x13()
libxul.so`MessageLoop::Run+0x38()
libxul.so`nsThread::ThreadFunc+0x97()
libnspr4.so`_pt_root+0xcb()
libc.so.1`_thrp_setup+0xb3()
libc.so.1`_lwp_start()

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to Petr Sumbera from comment #7)

We have seen the crash on Solaris i386 with TB 115.11.0

Under what circumstances? What did you do leading up to the crash?

Comment 9

[Petr Sumbera]

Difficult to answer. TB was running, I walked away from my laptop. I might have closed the lid to "suspend" it, and when I came back to it, TB had gone.

Comment 10

[Wayne Mery (:wsmwk)]

Possible to do comment 5?

Comment 11

[Wayne Mery (:wsmwk)]

Crash rate is unchanged between 115 and 128.

Comment 12

[Magnus Melin [:mkmelin]]

Someone more deeply into c++ would have to tackle that (comment 5).

Comment 13

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #4)

Ideas?

bp-d733c3b6-cba4-4cc4-b30a-a90c30231026 "It went out yesterday, too while trying to put a message in "Sent."
Bp-ad8a648a-5389-449d-81a1-c8aca0231027
Bp-b2248c0f-d9b1-4ba3-982f-757e10230927 "crash before / after hibernation"

bug 1891962 also has a high percentage associated with hibernate/sleep

bug 1766101 associated with compact is gone from version 128

Comment 14

[weathervane]

TB 128.3.1 esr
Crash ID: 62a4b07c-fdb7-46dd-9924-2da170241015
Crashes continue, even with only "Get All Mail" being the only add-on and "Dream of Waves" as the theme.

I had just send a couple of emails from a POP GMail account and then the pop-up crash report appeared. When I checked the log, it said the crash occurred about ten minutes before I sent the emails so apparently TB restarted itself and had me already logged in. Seems...odd.

2 GMail accounts running as POP; 1 GMail account as IMAP.

I'm unsure of how to proceed as all this is far above my skill level. I'm just posting in case this info might help.