386148 - "ASSERTION: nsImapMailboxSpec not thread-safe"

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[Scott MacGregor]

I just started running into this assertion in my debug build, either of you guys seeing this?

###!!! ASSERTION: nsImapMailboxSpec not thread-safe: '_mOwningThread.GetThread()
 == PR_GetCurrentThread()', file c:/build/trees/tb-trunk/mozilla/mailnews/imap/s
rc/nsImapUtils.cpp, line 236

Comment 1

[David :Bienvenu]

I think I have seen that recently - I'll try to look at a stack trace next time it happens. It might be that it happens when an imap connection gets dropped, and the imap protocol object gets released on the wrong thread.

Comment 2

[David :Bienvenu]

The UpdateMailboxInfo event (which gets proxied from the imap thread to the ui thread) has a reference to a mailbox spec, and is the last owner of the reference, so that when the event gets cleaned up, it releases the reference and the destructor is hit. I think this happens on the ui thread, but the mailbox spec is created on the imap thread. I'm not sure what changed about this, but I'll look a little more.

Comment 3

[David :Bienvenu]

it's not a last reference case - any release on the wrong thread causes this assertion. What's weird is that my fastmail.fm account has no problem, but my mozilla.com account does assert everytime a folder is selected.

Comment 4

[Scott MacGregor]

I wonder if this issue was triggered by Bug 337492.

Addref / Release calls are happening on the imap thread as I would expect. The only one that's on the wrong thread is when a nsIRunnable object gets destroyed, it's releasing our mailbox spec object. We could have been relying on an ordering problem that was changed with 337492. 

Comment 5

[Scott MacGregor]

sometimes I do see the nsIRunnable object release the mailbox spec on the imap thread. here's a stack trace where things are happening correctly:

>	nsImapMailboxSpec::Release() Line 236	C++
 	nsProxyObjectCallInfo::RefCountInInterfacePointers() Line 214	C++
 	nsProxyObjectCallInfo::~nsProxyObjectCallInfo() Line 153	C++
 	nsProxyObjectCallInfo::`scalar deleting destructor'()	C++
 	nsRunnable::Release() Line 51	C++
 	nsRefPtr<nsProxyObjectCallInfo>::~nsRefPtr<nsProxyObjectCallInfo>() Line 957	C++
 	nsProxyEventObject::CallMethod() Line 263	C++
 	PrepareAndDispatch() Line 114	C++
 	SharedStub() Line 142	C++
 	nsImapProtocol::UpdatedMailboxSpec() Line 3720	C++
 	nsImapProtocol::UpdatedMailboxSpec() Line 3720	C++
 	nsImapProtocol::ProcessMailboxUpdate() Line 3674	C++
 	nsImapProtocol::ProcessSelectedStateURL() Line 2258	C++
 	nsImapProtocol::ProcessCurrentURL() Line 1441	C++
 	nsImapProtocol::ImapThreadMainLoop() Line 1155	C++
 	nsImapProtocol::Run() Line 936	C++

Comment 6

[Scott MacGregor]

Stack trace where nsIRunnable releases nsImapMailboxSpec on the wrong thread...

>	nsImapMailboxSpec::Release() Line 236	C++
 	nsProxyObjectCallInfo::RefCountInInterfacePointers() Line 214	C++
 	nsProxyObjectCallInfo::~nsProxyObjectCallInfo() Line 153	C++
 	nsProxyObjectCallInfo::`scalar deleting destructor'()	C++
 	nsRunnable::Release() Line 51	C++
 	nsCOMPtr<nsIRunnable>::~nsCOMPtr<nsIRunnable>() Line 584	C++
 	nsThread::ProcessNextEvent() Line 492	C++
 	NS_ProcessNextEvent_P() Line 227	C++
 	nsBaseAppShell::Run() Line 154	C++
 	nsAppStartup::Run() Line 171	C++
 	XRE_main() Line 2810	C++

Comment 7

[David :Bienvenu]

Scott, it does sound like that bug is involved - but this only happens sometimes to me, which kinda implies that something random is still going on and perhaps bug 337492 isn't really fixed.

Comment 8

[Caio Tiago Oliveira (asrail)]

It looks like it's a dup of bug 351193, but I would prefer marking that as duplicate.

I got this assertion every time it checks for new IMAP mail and sometimes the whole interface hangs for a few seconds while downloading new mail or headers.

Running Linux 64 bits.

Comment 9

[Caio Tiago Oliveira (asrail)]

Just another info:
the IMAP account in question is a gmail imap account and I'm checking on new mail on all folders.

So generally new mail arrives on at least two folders at once (inbox and all mail).

Comment 11

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: both normal and full backtraces

Ran into this assertion while switching from an IMAP folder into downloading newsgroup messages. (I think)

Comment 12

[David :Bienvenu]

Attachment: this fixes the problem

this papers over the underlying problem, which sure sounds a lot like Bug 337492 - I don't know how much traction we're going to get on that though.  At least this silences the assertion, relatively cheaply.

Comment 13

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Also hit this assertion when leaving Thunderbird idle with an IMAP and a news account.

Comment 14

[David :Bienvenu]

have not seen this in a long time.