393935 - Crash [@ nsProxyObject::LockedFind]

Status: VERIFIED FIXED

(Core :: XPCOM, defect)

Description

[Jesse Ruderman]

I hit this crash while testing a Mac trunk debug build of Firefox, but I can't reproduce it.  Benjamin, if there isn't enough information here to be useful, please close the bug as inco or wfm.

Related to bug 350132?


Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x5f73746e

Thread 0 Crashed:
0   libxpcom_core.dylib      	0x01361ef8 nsProxyObject::LockedFind(nsID const&, void**) + 218 (nsProxyEvent.cpp:459)
1   libxpcom_core.dylib      	0x0136467d nsProxyObjectManager::GetProxyForObject(nsIEventTarget*, nsID const&, nsISupports*, int, void**) + 501 (nsProxyObjectManager.cpp:201)
2   libxpcom_core.dylib      	0x01364471 NS_GetProxyForObject(nsIEventTarget*, nsID const&, nsISupports*, int, void**) + 135 (nsProxyObjectManager.cpp:308)
3   libtoolkitcomps.dylib    	0x166eac3e nsUrlClassifierDBService::GetTables(nsIUrlClassifierCallback*) + 280 (nsUrlClassifierDBService.cpp:2193)
4   libxpcom_core.dylib      	0x0136d6e8 NS_InvokeByIndex_P + 98 (xptcinvoke_unixish_x86.cpp:179)
5   libxpconnect.dylib       	0x02a44602 XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) + 5176 (xpcwrappednative.cpp:2285)
6   libxpconnect.dylib       	0x02a4c0d4 XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*, long*) + 398 (xpcwrappednativejsops.cpp:1467)
7   libmozjs.dylib           	0x0105eb0f js_Invoke + 2968 (jsinterp.c:1378)
8   libmozjs.dylib           	0x010706a4 js_Interpret + 65852 (jsinterp.c:4111)
9   libmozjs.dylib           	0x0105eb9a js_Invoke + 3107 (jsinterp.c:1399)
10  libxpconnect.dylib       	0x02a3f585 nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) + 4959 (xpcwrappedjsclass.cpp:1457)
11  libxpconnect.dylib       	0x02a37d39 nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) + 97 (xpcwrappedjs.cpp:565)
12  libxpcom_core.dylib      	0x0136d9a2 PrepareAndDispatch(nsXPTCStubBase*, unsigned, unsigned*) + 662 (xptcstubs_unixish_x86.cpp:93)
13  libxpcom_core.dylib      	0x0136daf6 nsXPTCStubBase::Stub6() + 52 (xptcstubsdef.inc:8)
14  libxpcom_core.dylib      	0x0136d6e8 NS_InvokeByIndex_P + 98 (xptcinvoke_unixish_x86.cpp:179)
15  libxpconnect.dylib       	0x02a44602 XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) + 5176 (xpcwrappednative.cpp:2285)
16  libxpconnect.dylib       	0x02a4c0d4 XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*, long*) + 398 (xpcwrappednativejsops.cpp:1467)
17  libmozjs.dylib           	0x0105eb0f js_Invoke + 2968 (jsinterp.c:1378)
18  libmozjs.dylib           	0x010706a4 js_Interpret + 65852 (jsinterp.c:4111)
19  libmozjs.dylib           	0x0105eb9a js_Invoke + 3107 (jsinterp.c:1399)
20  libmozjs.dylib           	0x0105ef33 js_InternalInvoke + 312 (jsinterp.c:1474)
21  libmozjs.dylib           	0x0101e867 JS_CallFunctionValue + 60 (jsapi.c:4932)
22  libgklayout.dylib        	0x17db9090 nsJSContext::CallEventHandler(nsISupports*, void*, void*, nsIArray*, nsIVariant**) + 1224 (nsJSEnvironment.cpp:1842)
23  libgklayout.dylib        	0x17ddc0be nsGlobalWindow::RunTimeout(nsTimeout*) + 1778 (nsGlobalWindow.cpp:7098)
24  libgklayout.dylib        	0x17ddc5f0 nsGlobalWindow::TimerCallback(nsITimer*, void*) + 54 (nsGlobalWindow.cpp:7432)
25  libxpcom_core.dylib      	0x0135fef6 nsTimerImpl::Fire() + 892 (nsTimerImpl.cpp:385)
26  libxpcom_core.dylib      	0x013600a3 nsTimerEvent::Run() + 191 (nsTimerImpl.cpp:459)
27  libxpcom_core.dylib      	0x0135c4c9 nsThread::ProcessNextEvent(int, int*) + 627 (nsThread.cpp:491)
28  libxpcom_core.dylib      	0x013051d6 NS_ProcessNextEvent_P(nsIThread*, int) + 76 (nsThreadUtils.cpp:227)
29  libwidget_mac.dylib      	0x050454a6 nsBaseAppShell::Run() + 70 (nsBaseAppShell.cpp:153)
30  libwidget_mac.dylib      	0x050278e4 nsAppShell::Run() + 190 (nsAppShell.mm:355)
31  libwidget_mac.dylib      	0x05027c60 -[AppShellDelegate runAppShell] + 36 (nsAppShell.mm:459)
32  com.apple.Foundation     	0x9280b03b __NSFireDelayedPerform + 403
33  com.apple.CoreFoundation 	0x9082d7e2 CFRunLoopRunSpecific + 3341
34  com.apple.CoreFoundation 	0x9082cace CFRunLoopRunInMode + 61
35  com.apple.HIToolbox      	0x92ded8d8 RunCurrentEventLoopInMode + 285
36  com.apple.HIToolbox      	0x92decf19 ReceiveNextEventCommon + 184
37  com.apple.HIToolbox      	0x92dece39 BlockUntilNextEventMatchingListInMode + 81
38  com.apple.AppKit         	0x93293465 _DPSNextEvent + 572
39  com.apple.AppKit         	0x93293056 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 137
40  libwidget_mac.dylib      	0x050276db nsAppShell::ProcessNextNativeEvent(int) + 275 (nsAppShell.mm:309)
41  libwidget_mac.dylib      	0x0504544d nsBaseAppShell::DoProcessNextNativeEvent(int) + 51 (nsBaseAppShell.cpp:137)
42  libwidget_mac.dylib      	0x05045812 nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned) + 94 (nsBaseAppShell.cpp:225)
43  libwidget_mac.dylib      	0x050279a6 nsAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned) + 180 (nsAppShell.mm:379)
44  libxpcom_core.dylib      	0x0135c3c5 nsThread::ProcessNextEvent(int, int*) + 367 (nsThread.cpp:480)
45  libxpcom_core.dylib      	0x013052c3 NS_ProcessPendingEvents_P(nsIThread*, unsigned) + 91 (nsThreadUtils.cpp:180)
46  libwidget_mac.dylib      	0x050453e9 nsBaseAppShell::NativeEventCallback() + 83 (nsBaseAppShell.cpp:116)
47  libwidget_mac.dylib      	0x050282a3 nsAppShell::ProcessGeckoEvents() + 263 (nsAppShell.mm:220)
48  libwidget_mac.dylib      	0x050283ed -[AppShellDelegate handlePortMessage:] + 107 (nsAppShell.mm:450)
49  com.apple.Foundation     	0x928469c0 __NSFireMachPort + 307
50  com.apple.CoreFoundation 	0x9083d385 __CFMachPortPerform + 136
51  com.apple.CoreFoundation 	0x9082d62d CFRunLoopRunSpecific + 2904
52  com.apple.CoreFoundation 	0x9082cace CFRunLoopRunInMode + 61
53  com.apple.HIToolbox      	0x92ded8d8 RunCurrentEventLoopInMode + 285
54  com.apple.HIToolbox      	0x92decfe2 ReceiveNextEventCommon + 385
55  com.apple.HIToolbox      	0x92dece39 BlockUntilNextEventMatchingListInMode + 81
56  com.apple.AppKit         	0x93293465 _DPSNextEvent + 572
57  com.apple.AppKit         	0x93293056 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 137
58  com.apple.AppKit         	0x9328cddb -[NSApplication run] + 512
59  libwidget_mac.dylib      	0x050278b8 nsAppShell::Run() + 146 (nsAppShell.mm:352)
60  libtoolkitcomps.dylib    	0x166dbd59 nsAppStartup::Run() + 147 (nsAppStartup.cpp:170)
61  XUL                      	0x0020ff24 XRE_main + 10182 (nsAppRunner.cpp:3069)
62  org.mozilla.firefox      	0x00002798 main + 708 (nsBrowserApp.cpp:153)
63  org.mozilla.firefox      	0x00001dca _start + 216
64  org.mozilla.firefox      	0x00001cf1 start + 41

Comment 1

[Benjamin Smedberg]

Without locals, probably can't reproduce this. The only thing I can think of is if the object you're trying to proxy doesn't respond to QI(nsISupports) then you could end up with a null object at nsProxyEvent.cpp:459 but I would think that would have triggered asserts first.

If you see something like this again and can catch it in a debugger, dumping the members of the nsProxyObject would be useful.

Comment 2

[Jesse Ruderman]

Ok, thanks.

Comment 3

[Mats Palmgren (inactive)]

nsProxyObject::LockedFind has a worrying trend though...
and there seems to be some crashes that didn't crash on accessing 0x0...

http://crash-stats.mozilla.com/report/list?range_unit=months&query_search=signature&query_type=contains&signature=nsProxyObject%3A%3ALockedFind%28nsID+const%26%2C+void%2A%2A%29&query=nsProxyObject%3A%3ALockedFind&range_value=1

Comment 4

[Benjamin Smedberg]

Attachment: Boy, I hate proxy threading, rev. 1

Let nobody say that arbitrary threading isn't insane. I think what's happening is there's a race with two threads:

* Thread A is calling GetProxyForObject. In nsProxyObjectManager.cpp#199 it finds a nsProxyObject in the map and proceeds

* Thread B is finishing a proxy call on the same nsProxyObject. It ends up in nsProxyObject::Release which locks

* Thread A unlocks at nsProxyEvent.cpp#451

* Thread B enters nsProxyObject::LockedRelease which frees the object, sets  and removes it from the global map, and nulls mRealObject

* Thread A calls mRealObject->QueryInterface and crashes

The solution is to make sure that GetProxyForObject holds a reference to the nsProxyObject whenever LockedFind is being called. This will keep it alive and avoid the Thread B Release from deleting the object.

Comment 5

[Brendan Eich [:brendan]]

Comment on attachment 278965 [details] [diff] [review]
Boy, I hate proxy threading, rev. 1


>+        nsProxyLockedRefPtr root =
>+            (nsProxyObject*) mProxyObjectMap.Get(&rootKey);

Assignment-style initialization, ok.

>-        nsProxyObject *root =
>-            (nsProxyObject*) mProxyObjectMap.Get(&rootKey);
>+        nsProxyLockedRefPtr root((nsProxyObject*) mProxyObjectMap.Get(&rootKey));

Call-style init, how come?

Looks great otherwise. Sorry I did not catch this on the last review.

/be

Comment 6

[Benjamin Smedberg]

Fixed on trunk with nit

Comment 7

[Benjamin Smedberg]

Verified: these crashes have disappeared from crash-stats.m.c.