405025 - ASSERT_VALID_LOCK failed

Status: RESOLVED FIXED

(Other Applications Graveyard :: Venkman JS Debugger, defect)

Description

[Bruno Calvignac]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: 

This happened on startup and resulted in a crash of the Flock application (happened twice in a month). Flock is using the FireFox 2.0.0.9 code base

I inspecting it under the debugger showed that the following assertion failed:
JS_ASSERT((! lock->count && ! lock->owner) || (lock->count && lock->owner));
but lock->count = 0 and lock->owner = null
which leads to believe that they were modified by another thread after the assertion failed.

Here is the call stack:
js3250.dll!JS_Assert(const char * s=0x01774228, const char * file=0x017741ec, int ln=106)  Line 59	C
jsd3250.dll!ASSERT_VALID_LOCK(JSDStaticLock * lock=0x013339d8)  Line 106 + 0x34	C
jsd3250.dll!jsd_Lock(JSDStaticLock * lock=0x013339d8)  Line 140 + 0x9	C
jsd3250.dll!jsd_ObjectHook(JSContext * cx=0x04506e48, JSObject * obj=0x078aa478, int isNew=1, void * closure=0x01302438)  Line 168 + 0xf	C
js3250.dll!js_NewObject(JSContext * cx=0x04506e48, JSClass * clasp=0x1014cb80, JSObject * proto=0x02698b20, JSObject * parent=0x078aa480)  Line 2487 + 0x23	C
js3250.dll!js_Interpret(JSContext * cx=0x04506e48, unsigned char * pc=0x03539318, long * result=0x0012df0c)  Line 4958 + 0x14	C
js3250.dll!js_Invoke(JSContext * cx=0x04506e48, unsigned int argc=3, unsigned int flags=1)  Line 1394 + 0x13	C
js3250.dll!js_InvokeConstructor(JSContext * cx=0x04506e48, long * vp=0x0453293c, unsigned int argc=3)  Line 1960 + 0xf	C
js3250.dll!js_Interpret(JSContext * cx=0x04506e48, unsigned char * pc=0x03539498, long * result=0x0012e944)  Line 3409 + 0x14	C
js3250.dll!SendToGenerator(JSContext * cx=0x04506e48, JSGeneratorOp op=JSGENOP_NEXT, JSObject * obj=0x07042858, JSGenerator * gen=0x079e3a18, long arg=-2147483647, long * rval=0x0012ea78)  Line 878 + 0x14	C
js3250.dll!generator_op(JSContext * cx=0x04506e48, JSGeneratorOp op=JSGENOP_NEXT, JSObject * obj=0x07042858, unsigned int argc=0, long * argv=0x07ad8fcc, long * rval=0x0012ea78)  Line 1009 + 0x1d	C
js3250.dll!generator_next(JSContext * cx=0x04506e48, JSObject * obj=0x07042858, unsigned int argc=0, long * argv=0x07ad8fcc, long * rval=0x0012ea78)  Line 1025 + 0x1b	C
js3250.dll!js_Invoke(JSContext * cx=0x04506e48, unsigned int argc=0, unsigned int flags=0)  Line 1375 + 0x20	C
js3250.dll!js_Interpret(JSContext * cx=0x04506e48, unsigned char * pc=0x052ae0a4, long * result=0x0012f5f0)  Line 3957 + 0xf	C
js3250.dll!js_Invoke(JSContext * cx=0x04506e48, unsigned int argc=1, unsigned int flags=2)  Line 1394 + 0x13	C
xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper=0x07195eb0, unsigned short methodIndex=3, const nsXPTMethodInfo * info=0x033cf940, nsXPTCMiniVariant * nativeParams=0x0012f960)  Line 1462 + 0x14	C++
xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=3, const nsXPTMethodInfo * info=0x033cf940, nsXPTCMiniVariant * params=0x0012f960)  Line 468	C++
xpcom_core.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x07195eb0, unsigned int methodIndex=3, unsigned int * args=0x0012fa28, unsigned int * stackBytesToPop=0x0012fa18)  Line 117 + 0x1c	C++
xpcom_core.dll!SharedStub()  Line 147	C++
xpcom_core.dll!nsTimerImpl::Fire()  Line 411	C++
xpcom_core.dll!nsTimerManager::FireNextIdleTimer()  Line 657	C++
gkwidget.dll!nsAppShell::Run()  Line 142	C++
tkitcmps.dll!nsAppStartup::Run()  Line 151 + 0x1a	C++
flock.exe!XRE_main(int argc=1, char * * argv=0x01291bb0, const nsXREAppData * aAppData=0x0042709c)  Line 2895 + 0x23	C++
flock.exe!main(int argc=1, char * * argv=0x01291bb0)  Line 78 + 0x12	C++
flock.exe!mainCRTStartup()  Line 398 + 0x11	C
kernel32.dll!75c53833()
ntdll.dll!7713a9bd()

Here is the threads list:
5576	main	JS_Assert	Normal	0
4728	Win32 Thread	77160f34	Normal	0
2472	pr_root	_PR_MD_WAIT_CV	Normal	0
984	pr_root	PR_IntervalToMicroseconds	Normal	0
5168	pr_root	nsNotifyAddrListener::Run	Normal	0
4804	pr_root	_PR_MD_WAIT_CV	Normal	0
6064	pr_root	_PR_MD_WAIT_CV	Normal	0
5904	pr_root	PR_GetThreadPrivate	Below Normal	0
1520	Win32 Thread	77160f34	Normal	0
5556	pr_root	_PR_MD_WAIT_CV	Normal	0
5884	pr_root	_PR_MD_WAIT_CV	Normal	0
5812	pr_root	PR_GetThreadPrivate	Normal	0


Reproducible: Couldn't Reproduce

Steps to Reproduce:
1.
2.
3.



This is js stack:
0 set_up_field(f = "screenName") ["chrome://flock/content/common/coop.js":385]
    field_type = undefined
    field_rsrc = undefined
    field_enumerator = undefined
    this = [object BackstagePass]
1 coop_obj_ctor(uri = "urn:flock:identity:facebook:540106978:560147316", field_values = null, 
resource = [xpconnect wrapped nsIRDFResource @ 0x6ce2bf8 (native @ 0x359b1e0)]) ["chrome://flock/content/common/coop.js":401]
    get_id = undefined
    firstTime = false
    hashtable = undefined
    container = undefined
    set_up_field = [function]
    f = "screenName"
    instance = [object Object]
    type = [object Object]
    this = [object Object]
2 Coop_get_from_resource(aResource = [xpconnect wrapped nsIRDFResource @ 0x6ce2bf8 (native @ 0x359b1e0)], 
aURI = "urn:flock:identity:facebook:540106978:560147316") 
["chrome://flock/content/common/coop.js":868]
3 container_enum_getNext() ["chrome://flock/content/common/coop.js":282]
4 updateAccountContent(aShouldYield = [function]) ["chrome://flock/content/people/peopleSidebar.js":472]
5 [native frame]
6 FlockScheduler_callback_notify(aTimer = [xpconnect wrapped nsITimer @ 0x6f942f8 (native @ 0x6f94158)]) 
["file:///C:/build/flock-trunk/objectdir/dist/bin/modules/FlockScheduler.jsm":92]
7 [native frame]

Comment 1

[timeless]

yes the assertion itself is not threadsafe. :)

i never got around to figuring out what to do about it. i think it'd require 1 more global lock just for the specific purpose of lock assertion.

it's quite possible i filed a bug for this. it's also possible i didn't :)

Comment 2

[:Gijs (he/him)]

(In reply to comment #1)
> yes the assertion itself is not threadsafe. :)
> 
> i never got around to figuring out what to do about it. i think it'd require 1
> more global lock just for the specific purpose of lock assertion.
> 
> it's quite possible i filed a bug for this. it's also possible i didn't :)
> 

So is this an actual jsd bug or not? I'm confused. :-)

Comment 3

[timeless]

Attachment: split assertion so that it can't race

for people who are curious, jsd_IsLocked means jsd_IsLockedByMe.

Comment 4

[Bruno Calvignac]

Thank you very much for the patch. I have applied it to my build and will let you know if it happens again (in the last couple of months, it happened to me once every week or two)

Comment 5

[:Gijs (he/him)]

Comment on attachment 304164 [details] [diff] [review]
split assertion so that it can't race

>Index: jsd_lock.c
> <snip>
>+    /* it's an error to unlock a lock you don't own */
>+    JS_ASSERT(lock->owner == me);
>     if(lock->owner != me)
>     {
>-        JS_ASSERT(0);   /* it's an error to unlock a lock you don't own */
>         return;
>     }
>     if(--lock->count == 0)

Nit: Please remove braces for the one-line if statement.

Other than that it looks good to me, r=me.

Comment 6

[Damon Sicore (:damons)]

Comment on attachment 304164 [details] [diff] [review]
split assertion so that it can't race

a1.9+=damons

Comment 7

[timeless]

Comment on attachment 304164 [details] [diff] [review]
split assertion so that it can't race

mozilla/js/jsd/jsd_lock.c 	3.9
mozilla/js/jsd/jsd_lock.c 	3.10