1369595 - Potential deadlock detected in nsTimerImpl

Status: RESOLVED DUPLICATE of bug 1370448

(Core :: Networking, enhancement)

Description

[JW Wang [:jwwang] [:jw_wang]]

https://treeherder.mozilla.org/logviewer.html#?job_id=103915537&repo=try&lineNumber=44178

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Are you need info'ing me because you think this might be related to bug 1363829?
 
Unfortunately, looking at the error message this does not seem to use nsGlobalWindow::SetTimeout() at all.  Its nsITimer usage within nsSocketTransportService:
 
19:20:00     INFO - GECKO(2240) | === Cyclical dependency starts at
19:20:00     INFO - GECKO(2240) | --- Mutex : TimerThread.mMonitor calling context
19:20:00     INFO - GECKO(2240) |   [stack trace unavailable]
19:20:00     INFO - GECKO(2240) | --- Next dependency:
19:20:00     INFO - GECKO(2240) | --- Mutex : nsSocketTransportService::mLock (currently acquired)
19:20:00     INFO - GECKO(2240) |  calling context
19:20:00     INFO - GECKO(2240) |   [stack trace unavailable]
19:20:00     INFO - GECKO(2240) | --- Next dependency:
19:20:00     INFO - GECKO(2240) | --- Mutex : nsTimerImpl::mMutex (currently acquired)
19:20:00     INFO - GECKO(2240) |  calling context
19:20:00     INFO - GECKO(2240) |   [stack trace unavailable]
19:20:00     INFO - GECKO(2240) | === Cycle completed at
19:20:00     INFO - GECKO(2240) | --- Mutex : TimerThread.mMonitor calling context
19:20:00     INFO - GECKO(2240) |   [stack trace unavailable]
 
It seems somehow this shutdown code path is triggering a potential deadlock:
 
https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsSocketTransportService2.cpp#806
 
19:20:00     INFO - GECKO(2240) | #01: mozilla::OffTheBooksMutex::Lock() [xpcom/threads/BlockingResourceBase.cpp:383]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #02: nsTimerImpl::InitCommon(unsigned int,unsigned int,nsTimerImpl::Callback &&) [xpcom/threads/nsTimerImpl.cpp:216]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #03: nsTimerImpl::Init(nsIObserver *,unsigned int,unsigned int) [xpcom/threads/nsTimerImpl.cpp:310]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #04: nsTimer::Init(nsIObserver *,unsigned int,unsigned int) [xpcom/threads/nsTimerImpl.h:227]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #05: mozilla::net::nsSocketTransportService::StartPollWatchdog() [netwerk/base/nsSocketTransportService2.cpp:1622]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #06: mozilla::net::nsSocketTransportService::OnDispatchedEvent(nsIThreadInternal *) [netwerk/base/nsSocketTransportService2.cpp:810]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #07: nsThread::PutEvent(already_AddRefed<nsIRunnable>,nsThread::nsNestedEventTarget *) [xpcom/threads/nsThread.cpp:750]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #08: nsThread::DispatchInternal(already_AddRefed<nsIRunnable>,unsigned int,nsThread::nsNestedEventTarget *) [xpcom/threads/nsThread.cpp:808]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #09: nsThread::Dispatch(already_AddRefed<nsIRunnable>,unsigned int) [xpcom/threads/nsThread.cpp:867]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #10: mozilla::net::nsSocketTransportService::Dispatch(already_AddRefed<nsIRunnable>,unsigned int) [netwerk/base/nsSocketTransportService2.cpp:153]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #11: nsIEventTarget::Dispatch(nsIRunnable *,unsigned int) [obj-firefox/dist/include/nsIEventTarget.h:37]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #12: mozilla::net::nsHttpConnectionMgr::PostEvent(void ( mozilla::net::nsHttpConnectionMgr::*)(int,mozilla::net::ARefBase *),int,mozilla::net::ARefBase *) [netwerk/protocol/http/nsHttpConnectionMgr.cpp:273]
19:20:00     INFO -
19:20:00     INFO - GECKO(2240) | #13: mozilla::net::nsHttpConnectionMgr::Shutdown() [netwerk/protocol/http/nsHttpConnectionMgr.cpp:218]
19:20:00     INFO -

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Maybe Nathan would have some ideas on how this is deadlocking.  Its not immediately obvious to me.

Comment 3

[Nathan Froyd [:froydnj]]

(In reply to Ben Kelly [reviewing, but slowly][:bkelly] from comment #2)
> Maybe Nathan would have some ideas on how this is deadlocking.  Its not
> immediately obvious to me.

I don't see how either: TimerThread.mMonitor isn't locked anywhere in that stack.  I think it could be locked beneath nsTimerImpl::InitCommon if the stack is somehow wrong, but then I don't see how it could be locked beforehand.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

Looks like Ehsan is fixing it over in bug 1370448.