deadlock in nsImapProtocol::SendData if UI thread tries to check CanHandleUrl()

RESOLVED FIXED in Thunderbird 11.0


MailNews Core
Networking: IMAP
6 years ago
6 years ago


(Reporter: Bienvenu, Assigned: Bienvenu)



Thunderbird 11.0
Windows 7

Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
I ran into a deadlock with uploading a message to an imap folder - nsImapProtocol::SendData enter a monitor on the protocol object


before writing data to the output stream.

Then, the UI thread comes along and tries to see if the protocol object can handle a URL, CanHandleUrl calls nsImapProtocol::IsBusy, which calls   NS_LOCK_INSTANCE();, which is PR_CEnterMonitor(this), which is deadlock. Not quite sure why the SendData call is blocking on something happening on the UI thread, but it is. I wonder if fixing nsSyncRunnable not to use the event queue might help...

if not, IsBusy probably doesn't have to ener the monitor, or, SendData could use a separate monitor for the output stream.
Severity: normal → critical
Keywords: hang
David's reproduction suggestions - I'm trying them now...

09:51 (bienvenu) possible steps would be -
09:51 (bienvenu) set the number of cached connections to 1 or 2 in advanced imap server settings (might be easier to see if you do this, not sure)
09:51 (bienvenu) copy a large local message up to an imap server
09:52 (bienvenu) while that's going on, click on get new mail, or somehow cause an imap url to get run
09:52 (bienvenu) then figure out if comm-beta or aurora has the same bug
09:52 (bienvenu) if so, then it's not the sync runnable changes
09:54 (bienvenu) if not, then the fix to try would be to do what I suggest in
09:54 (firebot) Bug 675407 nor, --, Thunderbird 10.0, dbienvenu, RESO FIXED, Remove XPCOM proxies from comm-central

Comment 2

6 years ago
this happens in comm-beta as well, so it's not caused by the xpcom proxy removal.

Comment 3

6 years ago
Created attachment 569569 [details] [diff] [review]
proposed fix

this fixes the hang for me, which I can fairly easily reproduce on Windows. The code that touches m_urlInProgress from the imap thread already has the protocol's mLock. The other code that touches m_urlInProgress is run on the UI thread, so there won't be a race there.
Assignee: nobody → dbienvenu
Attachment #569569 - Flags: review?(irving)
Attachment #569569 - Flags: review?(irving) → review+
David does this needs commiting ?

Comment 5

6 years ago
yeah, I'll land it soon.

Comment 6

6 years ago
fixed on trunk -
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 11.0
You need to log in before you can comment on or make changes to this bug.