435090 - XPConnect request unsafety

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Benjamin Smedberg]

I am writing a testcase for bug 433005 and found an xpconnect request unsafety which is causing a deadlock. The stack is:

#0  0xffffe410 in __kernel_vsyscall ()
#1  0x003e75d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xf7d1e827 in PR_WaitCondVar (cvar=0x80c76a8, timeout=4294967295)
    at ../../../../../src/nsprpub/pr/src/pthreads/ptsynch.c:405
#3  0xf7f40a13 in ClaimTitle (title=0x81044bc, cx=0x81216b8) at ../../../src/js/src/jslock.cpp:484
#4  0xf7f40ba7 in js_LockTitle (cx=0x81216b8, title=0x81044bc) at ../../../src/js/src/jslock.cpp:1046
#5  0xf7f40d50 in js_LockObj (cx=0x81216b8, obj=0x80eb1a0) at ../../../src/js/src/jslock.cpp:1206
#6  0xf7f4afd5 in js_LookupPropertyWithFlags (cx=0x81216b8, obj=0x80eb1a0, id=135148236, flags=0, objp=0xf6c8ecac, 
    propp=0xf6c8eca8) at ../../../src/js/src/jsobj.cpp:3269
#7  0xf7f4c912 in js_LookupProperty (cx=0x81216b8, obj=0x80eb1a0, id=135148236, objp=0xf6c8ecac, propp=0xf6c8eca8)
    at ../../../src/js/src/jsobj.cpp:3234
#8  0xf7ec7ca7 in LookupProperty (cx=0x81216b8, obj=0x80eb1a0, name=0xf7a5d26d "Components", objp=0xf6c8ecac, 
    propp=0xf6c8eca8) at ../../../src/js/src/jsapi.cpp:3235
#9  0xf7ecae6a in JS_LookupProperty (cx=0x81216b8, obj=0x80eb1a0, name=0xf7a5d26d "Components", vp=0xf6c8ecec)
    at ../../../src/js/src/jsapi.cpp:3474
#10 0xf7a391bb in DEBUG_CheckForComponentsInScope (ccx=@0xf6c8ed88, obj=0x80eb1a0, OKIfNotInitialized=0)
    at ../../../../../src/js/src/xpconnect/src/xpcwrappednativescope.cpp:753
#11 0xf7a394a8 in XPCWrappedNativeScope::FindInJSObjectScope (ccx=@0xf6c8ed88, obj=0x80eb1a0, OKIfNotInitialized=0)
    at ../../../../../src/js/src/xpconnect/src/xpcwrappednativescope.cpp:804
#12 0xf7a1e239 in GetContextFromObject (obj=0x80eb660) at ../../../../../src/js/src/xpconnect/src/xpcwrappedjsclass.cpp:520
#13 0xf7a1f217 in nsXPCWrappedJSClass::CallMethod (this=0x8121410, wrapper=0x8106ac0, methodIndex=3, info=0x810b2b0, 
    nativeParams=0xf6c8f180) at ../../../../../src/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1130
#14 0xf7a17471 in nsXPCWrappedJS::CallMethod (this=0x8106ac0, methodIndex=3, info=0x810b2b0, params=0xf6c8f180)
    at ../../../../../src/js/src/xpconnect/src/xpcwrappedjs.cpp:559
#15 0xf7e622ca in PrepareAndDispatch (methodIndex=3, self=0x8121440, args=0xf6c8f244)
    at ../../../../../../../src/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp:95
#16 0xf7e44f3b in nsThread::ProcessNextEvent (this=0x810be18, mayWait=1, result=0xf6c8f2e0)
    at ../../../src/xpcom/threads/nsThread.cpp:510
#17 0xf7dcf224 in NS_ProcessNextEvent_P (thread=0x810be18, mayWait=1) at nsThreadUtils.cpp:227
#18 0xf7e45a0b in nsThread::ThreadFunc (arg=0x810be18) at ../../../src/xpcom/threads/nsThread.cpp:254
#19 0xf7d25ff8 in _pt_root (arg=0x810c080) at ../../../../../src/nsprpub/pr/src/pthreads/ptthread.c:221
#20 0x003e350b in start_thread () from /lib/libpthread.so.0

XPCWrappedNativeScope::FindInJSObjectScope is called without a request, which I believe is correct. But internally it calls some JSAPI functions, some of which I'm sure need requests. At the very least DEBUG_CheckForComponentsInScope should have a request, but what about JS_GetGlobalForObject ?

Comment 1

[Benjamin Smedberg]

This is deadlock against, I think, the main thread in GC:

#0  0xffffe410 in __kernel_vsyscall ()
#1  0x003ea119 in __lll_lock_wait () from /lib/libpthread.so.0
#2  0x003e58dd in _L_lock_839 () from /lib/libpthread.so.0
#3  0x003e580f in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0xf7d1dfd9 in PR_Lock (lock=0x80e6e14) at ../../../../../src/nsprpub/pr/src/pthreads/ptsynch.c:206
#5  0xf7d1eced in PR_EnterMonitor (mon=0x80e6e10) at ../../../../../src/nsprpub/pr/src/pthreads/ptsynch.c:531
#6  0xf79de52f in XPCAutoLock (this=0xffc6f36c, lock=0x80e6e10) at ../../../../../src/js/src/xpconnect/src/xpcprivate.h:324
#7  0xf7a1819d in ~nsXPCWrappedJS (this=0x81068d0) at ../../../../../src/js/src/xpconnect/src/xpcwrappedjs.cpp:460
#8  0xf7a18700 in nsXPCWrappedJS::Release (this=0x81068d0) at ../../../../../src/js/src/xpconnect/src/xpcwrappedjs.cpp:237
#9  0xf7e6111a in nsXPTCStubBase::Release (this=0x8106910) at ../../../../../src/xpcom/reflect/xptcall/src/xptcall.cpp:65
#10 0xf7e4c151 in nsTimerImpl::ReleaseCallback (this=0x8106630) at ../../../src/xpcom/threads/nsTimerImpl.h:121
#11 0xf7e4af5d in ~nsTimerImpl (this=0x8106630) at ../../../src/xpcom/threads/nsTimerImpl.cpp:162
#12 0xf7e4bd09 in nsTimerImpl::Release (this=0x8106630) at ../../../src/xpcom/threads/nsTimerImpl.cpp:95
#13 0xf7e4c812 in TimerThread::ReleaseTimerInternal (this=0x80550b0, aTimer=0x8106630)
    at ../../../src/xpcom/threads/TimerThread.cpp:456
#14 0xf7e4c9e9 in TimerThread::RemoveTimerInternal (this=0x80550b0, aTimer=0x8106630)
    at ../../../src/xpcom/threads/TimerThread.cpp:448
#15 0xf7e4cb27 in TimerThread::RemoveTimer (this=0x80550b0, aTimer=0x8106630)
    at ../../../src/xpcom/threads/TimerThread.cpp:398
#16 0xf7e4bd8b in nsTimerImpl::Release (this=0x8106630) at ../../../src/xpcom/threads/nsTimerImpl.cpp:132
#17 0xf7a0d9de in XPCJSRuntime::GCCallback (cx=0x80c77d0, status=JSGC_END)
    at ../../../../../src/js/src/xpconnect/src/xpcjsruntime.cpp:818
#18 0xf7f1ca5b in js_GC (cx=0x80c77d0, gckind=GC_LOCK_HELD) at ../../../src/js/src/jsgc.cpp:3526
#19 0xf7f55330 in js_SetProtoOrParent (cx=0x80c77d0, obj=0x80eba20, slot=0, pobj=0x80eda48)
    at ../../../src/js/src/jsobj.cpp:302
#20 0xf7ec5e48 in JS_SetPrototype (cx=0x80c77d0, obj=0x80eba20, proto=0x80eda48) at ../../../src/js/src/jsapi.cpp:2929
#21 0xf7a30a9b in xpc_CloneJSFunction (ccx=@0xffc6f994, funobj=0x81201c0, parent=0x80eb780)
    at ../../../../../src/js/src/xpconnect/src/xpcwrappednativeinfo.cpp:72
#22 0xf79faf10 in XPCNativeMember::NewFunctionObject (this=0x81074e8, ccx=@0xffc6f994, iface=0x81074b8, parent=0x80eb780, 
    pval=0xffc6f8f4) at ../../../../../src/js/src/xpconnect/src/xpcprivate.h:1399

Comment 2

[Johnny Stenback (:jst)]

(In reply to comment #0)
> XPCWrappedNativeScope::FindInJSObjectScope is called without a request, which I
> believe is correct. But internally it calls some JSAPI functions, some of which
> I'm sure need requests. At the very least DEBUG_CheckForComponentsInScope
> should have a request, but what about JS_GetGlobalForObject ?

Yes, DEBUG_ChrvkGotVomponrnydInScope() needs a request, but techincally JS_GetGlobalForObject() doesn't as it only uses OBJ_GET_PARENT(), which is defined to be STOBJ_GET_PARENT(), which does a direct obj->fslots[JSSLOT_PARENT] access. So no locking or requests needed there.

Comment 3

[Johnny Stenback (:jst)]

Wow, that's a pretty messed up typo, I meant DEBUG_CheckForComponentsInScope()
of course :)

Comment 4

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.