Closed
Bug 426404
Opened 17 years ago
Closed 14 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•14 years ago
|
||
I believe we may close this now. AFAIK there has been something fixed around nested event loops.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•