181102 - ###!!! ASSERTION: potential deadlock between XPCJSRuntime::mMapLockMonitor@10186f0 and nsComponentManagerImplMonitor@27ded0: 'Error'

Status: RESOLVED WORKSFORME

(Core :: XPConnect, defect)

Description

[timeless]

Reflow time (this=0858B5B8): Real time 0:0:0.160, CP time 0.090
Frame construction plus style resolution time (this=0858B5B8): Real time
0:0:3.54, CP time 2.884
Style resolution time (this=0858B5B8): Real time 0:0:3.295, CP time 2.984
WARNING: NS_ENSURE_TRUE(mDocument) failed, file
i:/build/mozilla/content/base/src/nsDocumentViewer.cpp, line 1184
WEBSHELL- = 11
###!!! ASSERTION: potential deadlock between
XPCJSRuntime::mMapLockMonitor@10186f0 and nsComponentManagerImplMonitor@27ded0:
'Error', file i:/build/mozilla/xpcom/threads/nsAutoLock.cpp, line 265
Break: at file i:/build/mozilla/xpcom/threads/nsAutoLock.cpp, line 265
###!!! ASSERTION: potential deadlock between
XPCJSRuntime::mMapLockMonitor@10186f0 and nsComponentManagerImplMonitor@27ded0:
'Error', file i:/build/mozilla/xpcom/threads/nsAutoLock.cpp, line 265
Break: at file i:/build/mozilla/xpcom/threads/nsAutoLock.cpp, line 265
there is no JSContext on the nsIThreadJSContextStack!
WARNING: NS_ENSURE_TRUE(mDocument) failed, file
i:/build/mozilla/content/base/src/nsDocumentViewer.cpp, line 1184
WEBSHELL- = 10
###!!! ASSERTION: stylesheet not found: 'Not Reached', file
i:/build/mozilla/content/base/src/nsDocument.cpp, line 1550
Break: at file i:/build/mozilla/content/base/src/nsDocument.cpp, line 1550
WEBSHELL- = 9
WEBSHELL- = 8

Unfortunately i had disabled notification for assertions, so no stack, i'll try
to reproduce this, but it won't happen until i get back. 

I think this was the result of a very long GC after mozilla had been swapped out
for a long time. note that i had done a few theme switches and run cview.

Comment 1

[Brendan Eich [:brendan]]

This is probably real, but a stack would help quite a bit.  Otherwise, we have
to dig through all the code at
http://lxr.mozilla.org/mozilla/search?string=GetMapLock and analyze control flow
by source inspection.

I bet ordinarily the CM monitor encloses an mMapLock, but that there are cases
where the order is the other way around.  That can make for an ABBA deadlock if
two threads can race through the two orders forthe same mMapLock.

/be

Comment 2

[Carsten Book [:Tomcat]]

Attachment: stack

i was running into this assertion while i tried to view videos from the new video feature testpage http://www.double.co.nz/video_test/test1.html and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080826054244 Minefield/3.1a2pre

My steps to reproduce were watching video 1 and stop the video and close Firefox.

*** Potential deadlock between XPCJSRuntime::mMapLockMonitor@10d74a0 and nsCompo
nentManagerImplMonitor@10401f8

Current stack:
nsAutoMonitor::nsAutoMonitor[xpcom_core +0x154E5]
nsComponentManagerImpl::GetServiceByContractID[xpcom_core +0x717E8]
CallGetService[xpcom_core +0xBCAD]
nsGetServiceByContractID::operator()[xpcom_core +0xC1DF]
nsCOMPtr<nsIObserverService>::assign_from_gs_contractid[gklayout +0x7709]
nsCOMPtr<nsIObserverService>::nsCOMPtr<nsIObserverService>[gklayout +0x70A4]
nsGlobalWindow::~nsGlobalWindow[gklayout +0x43F44D]
nsGlobalWindow::`scalar deleting destructor'[gklayout +0x43F1BF]
nsGlobalWindow::Release[gklayout +0x440803]
nsCOMPtr<nsIScriptObjectPrincipal>::~nsCOMPtr<nsIScriptObjectPrincipal>[xpc3250
+0x281FC]
XPCWrappedNativeScope::~XPCWrappedNativeScope[xpc3250 +0x6AA4E]
XPCWrappedNativeScope::`scalar deleting destructor'[xpc3250 +0x6A3EF]
XPCWrappedNativeScope::KillDyingScopes[xpc3250 +0x6B5AD]
XPCWrappedNativeScope::FinishedFinalizationPhaseOfGC[xpc3250 +0x6B131]
XPCJSRuntime::GCCallback[xpc3250 +0x3DA9C]
DOMGCCallback[gklayout +0x46DFED]
js_GC[js3250 +0x666F6]
js_DestroyContext[js3250 +0x2EB90]
JS_DestroyContext[js3250 +0x15C6E]
nsXPConnect::ReleaseJSContext[xpc3250 +0x10BD8]
nsJSContext::Unlink[gklayout +0x467D5C]
nsJSContext::~nsJSContext[gklayout +0x467BC5]
nsJSContext::`scalar deleting destructor'[gklayout +0x467AFF]
nsJSContext::Release[gklayout +0x4681C3]
nsCOMPtr<nsITimerCallback>::assign_assuming_AddRef[xpcom_core +0x81D09]
nsCOMPtr<nsITimerCallback>::assign_with_AddRef[xpcom_core +0x81C07]
nsCOMPtr<nsITimerCallback>::operator=[xpcom_core +0x81933]
nsTimerImpl::Fire[xpcom_core +0x813B7]
nsTimerEvent::Run[xpcom_core +0x814E1]
nsThread::ProcessNextEvent[xpcom_core +0x8310A]
NS_ProcessNextEvent_P[xpcom_core +0x16083]
nsThread::Shutdown[xpcom_core +0x82DC1]
nsOggDecoder::Stop[gklayout +0x4E757C]
nsOggDecoder::Shutdown[gklayout +0x4E6ACE]
nsOggDecoder::Observe[gklayout +0x4E8425]
nsObserverList::NotifyObservers[xpcom_core +0x43625]
nsObserverService::NotifyObservers[xpcom_core +0x2AA9F]
NS_ShutdownXPCOM_P[xpcom_core +0x231AF]
ScopedXPCOMStartup::~ScopedXPCOMStartup[xul +0x86EE]
XRE_main[xul +0xCE8C]
NS_internal_main[firefox +0x1A82]
wmain[firefox +0x1249]
__tmainCRTStartup[firefox +0x25C6]
wmainCRTStartup[firefox +0x241D]
RegisterWaitForInputIdle[kernel32 +0x17067]

Previous stack:
XPCAutoLock::XPCAutoLock[xpc3250 +0xE0A6]
nsXPCWrappedJS::Release[xpc3250 +0x49562]
nsXPTCStubBase::Release[xpcom_core +0x952A7]
nsCOMPtr_base::~nsCOMPtr_base[xpcom_core +0xA91B]
nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>[xpcom_core +0x886F]
nsComponentManagerImpl::GetServiceByContractID[xpcom_core +0x719FC]
CallGetService[xpcom_core +0xBCAD]
nsGetServiceByContractIDWithError::operator()[xpcom_core +0xC23F]
nsCOMPtr_base::assign_from_gs_contractid_with_error[xpcom_core +0xAB1B]
nsCOMPtr<nsISupports>::operator=[embedcomponents +0x199B8]
nsAppStartupNotifier::Observe[embedcomponents +0x197ED]
XRE_main[xul +0xBAC3]
NS_internal_main[firefox +0x1A82]
wmain[firefox +0x1249]
__tmainCRTStartup[firefox +0x25C6]
wmainCRTStartup[firefox +0x241D]
RegisterWaitForInputIdle[kernel32 +0x17067]

Comment 3

[Andrew McCreight [:mccr8]]

XPConnect is single threaded now, so I don't think deadlocks like this will still be an issue.