Closed
Bug 426404
Opened 16 years ago
Closed 12 years ago
Deadlock at nsHttpConnectionMgr::Shutdown
Categories
(Core :: Networking: HTTP, defect)
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
Assignee | ||
Comment 2•12 years ago
|
||
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.
Description
•