574466 - Assertion in ClaimTitle with workers (js1_8_5/extensions/worker-fib.js)

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Jason Orendorff [:jorendorff]]

python tests/jstests.py ./md-objdir/js js1_8_5/extensions/worker-fib.js

Assertion failure: ownercx->requestDepth > 0, at ../jslock.cpp:599

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
[Switching to process 70404 thread 0x2703]
0x00165463 in JS_Assert (s=0x1fe71e "ownercx->requestDepth > 0", file=0x1fe4e4 "../jslock.cpp", ln=599) at ../jsutil.cpp:77
77	    *((int *) NULL) = 0;  /* To continue from here in GDB: "return" then "continue". */
(gdb) bt
#0  0x00165463 in JS_Assert (s=0x1fe71e "ownercx->requestDepth > 0", file=0x1fe4e4 "../jslock.cpp", ln=599) at ../jsutil.cpp:77
#1  0x000c840e in ClaimTitle (title=0x40cc08, cx=0x823a00) at ../jslock.cpp:599
#2  0x000c86d2 in js_LockTitle (cx=0x823a00, title=0x40cc08) at ../jslock.cpp:1223
#3  0x000c8853 in js_LockObj (cx=0x823a00, obj=0x1127020) at ../jslock.cpp:1344
#4  0x000d68b2 in js_LookupPropertyWithFlags (cx=0x823a00, obj=0x1127020, id=17826100, flags=65535, objp=0xb038c550, propp=0xb038c54c) at ../jsobj.cpp:4449
#5  0x000d7b91 in js_FindPropertyHelper (cx=0x823a00, id=17826100, cacheResult=1, objp=0xb038c8bc, pobjp=0xb038c8b8, propp=0xb038c894) at ../jsobj.cpp:4516
#6  0x000ad14d in js_Interpret (cx=0x823a00) at jsops.cpp:2205
#7  0x000be872 in Invoke (cx=0x823a00, fun=0x1122000, script=0x41daf0, native=0, args=@0xb038cd6c, flags=0) at jsinterp.cpp:561
#8  0x000beec4 in js_Invoke (cx=0x823a00, args=@0xb038cd6c, flags=0) at jsinterp.cpp:652
#9  0x000bf3f3 in js_InternalInvoke (cx=0x823a00, obj=0x1117180, fval=17973312, flags=0, argc=1, argv=0xb038ce34, rval=0xb038ce30) at jsinterp.cpp:695
#10 0x0001b42d in JS_CallFunctionName (cx=0x823a00, obj=0x1117180, name=0x1f0a64 "onmessage", argc=1, argv=0xb038ce34, rval=0xb038ce30) at ../jsapi.cpp:4715
#11 0x00015d38 in js::detail::Event::dispatch (this=0x41e350, cx=0x823a00, thisobj=0x1117180, dataPropName=0x1ee67a "data", methodName=0x1f0a64 "onmessage", noHandler=js::detail::Event::ok) at ../../shell/jsworkers.cpp:333
#12 0x00015d8f in js::detail::DownMessageEvent::process (this=0x41e350, cx=0x823a00) at ../../shell/jsworkers.cpp:887
#13 0x0000dbf2 in js::detail::Worker::processOneEvent (this=0x41bbd0) at ../../shell/jsworkers.cpp:1087
#14 0x0000de5c in js::detail::WorkerQueue::work (this=0x413d00) at ../../shell/jsworkers.cpp:975
#15 0x00015fb5 in js::detail::ThreadPool::start (arg=0x413d00) at ../../shell/jsworkers.cpp:436
#16 0x00397892 in _pt_root (arg=0x414280) at /Users/jason/dev/tracemonkey/nsprpub/pr/src/pthreads/ptthread.c:228
#17 0x919f9155 in _pthread_start ()
#18 0x919f9012 in thread_start ()

The failing assertion in ClaimTitle is:

        /*
         ...
         * If title->u.link is non-null, title has already been inserted on
         * the rt->titleSharingTodo list, because another thread's context
         * already wanted to lock title while ownercx was running a request.
         * That context must still be in request and cannot be dead. Moreover,
         * the GC can not run at this moment as it must wait until all the
         * titles are shared and the threads that want to lock them finish
         * their requests. Thus we can claim the title if its thread matches
         * ours.
         */
        bool canClaim;
        if (title->u.link) {
            JS_ASSERT(js_ValidContextPointer(rt, ownercx));
            JS_ASSERT(ownercx->requestDepth > 0);

Shell workers do not share any objects among contexts, so we shouldn't be here at all.

Comment 1

[Jason Orendorff [:jorendorff]]

According to hg bisect:

The first bad revision is:
changeset:   42769:6b5e3d5422d9
user:        Brendan Eich <[e-mail]>
date:        Tue Jun 01 15:01:11 2010 -0700
summary:     Call instances uniquely shaped at birth due to lack of runtime-shared empty scope (569391, r=jorendorff).

But this should maybe be taken with a grain of salt, as the bug is sporadic.

Comment 2

[Jason Orendorff [:jorendorff]]

Gal tracked it down. This test has lots of Workers loading and running the same file. It creates some closures.

Each compartment has its own copy of the script and thus its own copy of the enclosing function. Different JSFunction, different JSScript, different Call object; but the Call objects are now sharing scopes, despite being isolated from each other in every other way.

Comment 3

[:Benjamin Peterson]

See bug 771281.