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.
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 https://bugzilla.mozilla.org/show_bug.cgi?id=675407#c50
09:54 (firebot) Bug 675407 nor, --, Thunderbird 10.0, dbienvenu, RESO FIXED, Remove XPCOM proxies from comm-central
this happens in comm-beta as well, so it's not caused by the xpcom proxy removal.
Created attachment 569569 [details] [diff] [review]
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.
David does this needs commiting ?
yeah, I'll land it soon.
fixed on trunk - http://hg.mozilla.org/comm-central/rev/a17719df870c