Closed Bug 426404 Opened 16 years ago Closed 12 years ago

Deadlock at nsHttpConnectionMgr::Shutdown

Categories

(Core :: Networking: HTTP, defect)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mayhemer, Assigned: mayhemer)

Details

(Keywords: hang)

During shutdown, while reproducing STR from bug 422978.

Main thread:

 	xpcom_core.dll!nsAutoMonitor::Wait(unsigned int interval=4294967295)  Line 340 + 0x11 bytes	C++
>	necko.dll!nsHttpConnectionMgr::Shutdown()  Line 157	C++
 	necko.dll!nsHttpHandler::Observe(nsISupports * subject=0x0465a570, const char * topic=0x1003cdf4, const wchar_t * data=0x1003dab4)  Line 1711	C++
 	xpcom_core.dll!nsObserverList::NotifyObservers(nsISupports * aSubject=0x0465a570, const char * aTopic=0x1003cdf4, const wchar_t * someData=0x1003dab4)  Line 129	C++
 	xpcom_core.dll!nsObserverService::NotifyObservers(nsISupports * aSubject=0x0465a570, const char * aTopic=0x1003cdf4, const wchar_t * someData=0x1003dab4)  Line 184	C++
 	xul.dll!nsXREDirProvider::DoShutdown()  Line 838	C++
 	xul.dll!ScopedXPCOMStartup::~ScopedXPCOMStartup()  Line 907	C++
 	xul.dll!XRE_main(int argc=3, char * * argv=0x00bc7cc0, const nsXREAppData * aAppData=0x00bc7f98)  Line 3200	C++
 	firefox.exe!NS_internal_main(int argc=3, char * * argv=0x00bc7cc0)  Line 158 + 0x12 bytes	C++
 	firefox.exe!wmain(int argc=3, wchar_t * * argv=0x00b9f7a0)  Line 87 + 0xd bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 594 + 0x19 bytes	C



nsSocketTransportService thread:

 	nspr4.dll!PR_Wait(PRMonitor * mon=0x043f4bd0, unsigned int ticks=4294967295)  Line 175 + 0x1d bytes	C
 	xpcom_core.dll!nsAutoMonitor::Wait(unsigned int interval=4294967295)  Line 340 + 0x11 bytes	C++
 	xpcom_core.dll!nsEventQueue::GetEvent(int mayWait=1, nsIRunnable * * result=0x01f6fa18)  Line 86	C++
 	xpcom_core.dll!nsThread::nsChainedEventQueue::GetEvent(int mayWait=1, nsIRunnable * * event=0x01f6fa18)  Line 113	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x01f6fa3c)  Line 501 + 0x49 bytes	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00c6c548, int mayWait=1)  Line 227 + 0x16 bytes	C++
 	xpcom_core.dll!nsProxyEventObject::CallMethod(unsigned short methodIndex=3, const XPTMethodDescriptor * methodInfo=0x00c4aa90, nsXPTCMiniVariant * params=0x01f6fae8)  Line 259 + 0xb bytes	C++
 	xpcom_core.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x0515f6e0, unsigned int methodIndex=3, unsigned int * args=0x01f6fba8, unsigned int * stackBytesToPop=0x01f6fb98)  Line 114 + 0x21 bytes	C++
 	xpcom_core.dll!SharedStub()  Line 142	C++
 	xpcom_core.dll!nsGetInterface::operator()(const nsID & aIID={...}, void * * aInstancePtr=0x0515f6e0)  Line 52 + 0x21 bytes	C++
 	xpcom_core.dll!nsGetInterface::operator()(const nsID & aIID={...}, void * * aInstancePtr=0x01f6fbdc)  Line 52 + 0x21 bytes	C++
 	pipnss.dll!nsCOMPtr<nsIDocShellTreeItem>::assign_from_helper(const nsCOMPtr_helper & helper={...}, const nsID & aIID={...})  Line 1335 + 0x13 bytes	C++
 	pipnss.dll!nsCOMPtr<nsIDocShellTreeItem>::nsCOMPtr<nsIDocShellTreeItem>(const nsCOMPtr_helper & helper={...})  Line 695	C++
 	pipnss.dll!nsNSSSocketInfo::SetNotificationCallbacks(nsIInterfaceRequestor * aCallbacks=0x04372854)  Line 348	C++
 	necko.dll!nsSocketTransport::BuildSocket(PRFileDesc * & fd=0x05385ac0, int & proxyTransparent=0, int & usingSSL=0)  Line 1044	C++
 	necko.dll!nsSocketTransport::InitiateSocket()  Line 1110 + 0x17 bytes	C++
 	necko.dll!nsSocketTransport::OnSocketEvent(unsigned int type=1, unsigned int status=0, nsISupports * param=0x043b3a58)  Line 1426 + 0x8 bytes	C++
 	necko.dll!nsSocketEvent::Run()  Line 99	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=0, int * result=0x01f6fe68)  Line 511	C++
 	xpcom_core.dll!NS_ProcessPendingEvents_P(nsIThread * thread=0x00c6c548, unsigned int timeout=4294967295)  Line 180 + 0x14 bytes	C++
 	necko.dll!nsSocketTransportService::Run()  Line 559	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x01f6ff08)  Line 511	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00c6c548, int mayWait=1)  Line 227 + 0x16 bytes	C++
 	xpcom_core.dll!nsThread::ThreadFunc(void * arg=0x00c6c548)  Line 254 + 0xb bytes	C++
 	nspr4.dll!_PR_NativeRunThread(void * arg=0x00c6cba0)  Line 436 + 0xf bytes	C
 	nspr4.dll!pr_root(void * arg=0x00c6cba0)  Line 122 + 0xf bytes	C
 	msvcr80d.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
 	msvcr80d.dll!_threadstartex(void * ptd=0x00c6d5c0)  Line 331	C


Apparently main thread is blocked while waiting for post finish of shutdown event posted on the socket thread. Socket thread is using synchronous proxy to the main thread. {socketThread}->mEvents.mQueue is empty (we are waiting for post to this queue), but {socketThread}->mEvents.mNext does contain chained queue where the posted event lies instead.

Seems to be some kind of core bug with chained queues?
160 nsHttpConnectionMgr::Shutdown()
161 {
162     LOG(("nsHttpConnectionMgr::Shutdown\n"));
163 
164     nsAutoMonitor mon(mMonitor);
165 
166     // do nothing if already shutdown
167     if (!mSocketThreadTarget)
168         return NS_OK;
169 
170     nsresult rv = PostEvent(&nsHttpConnectionMgr::OnMsgShutdown);
171 
172     // release our reference to the STS to prevent further events
173     // from being posted.  this is how we indicate that we are
174     // shutting down.
175     mIsShuttingDown = PR_TRUE;
176     mSocketThreadTarget = 0;
177 
178     if (NS_FAILED(rv)) {
179         NS_WARNING("unable to post SHUTDOWN message");
180         return rv;
181     }
182 
183     // wait for shutdown event to complete
we can't do this, we need to spin an event loop:
184     mon.Wait();
185     return NS_OK;
186 }
OS: Windows XP → All
I believe we may close this now.  AFAIK there has been something fixed around nested event loops.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.