Closed Bug 666963 Opened 12 years ago Closed 1 year ago

In js shell, on exit after using ctypes, Assertion failure: !rt->gcRunning, at js/src/jscntxt.cpp:586


(Core :: js-ctypes, defect)

Other Branch
Not set





(Reporter: jorendorff, Unassigned)



var fp_t = ctypes.FunctionType(ctypes.default_abi, ctypes.void_t).ptr;
var fp = new fp_t(function () {});

#0  JS_Assert (s=0x100373106 "!rt->gcRunning", file=0x100372c48 "js/src/jscntxt.cpp", ln=586) at js/src/jsutil.cpp:86
#1  js_DestroyContext (cx=0x100b0c280, mode=JSDCM_NO_GC) at js/src/jscntxt.cpp:586
#2  JS_DestroyContextNoGC (cx=0x100b0c280) at js/src/jsapi.cpp:1046
#3  js::ctypes::CType::FinalizeProtoClass (cx=0x100b016b0, obj=0x100d092e0) at js/src/ctypes/CTypes.cpp:2753
#4  JSObject::finalize (this=0x100d092e0, cx=0x100b016b0) at jsobjinlines.h:141
#5  js::gc::Arena::finalize<JSObject_Slots12> (this=0x100d09000, cx=0x100b016b0) at js/src/jsgc.cpp:252
#6  js::gc::FinalizeArenas<JSObject_Slots12> (cx=0x100b016b0, listHeadp=0x10180a058) at js/src/jsgc.cpp:297
#7  js::gc::ArenaList::finalizeNow<JSObject_Slots12> (this=0x10180a058, cx=0x100b016b0) at js/src/jsgc.cpp:1230
#8  JSCompartment::finalizeObjectArenaLists (this=0x101809e00, cx=0x100b016b0) at js/src/jsgc.cpp:2011
#9  MarkAndSweep (cx=0x100b016b0, comp=0x0, gckind=GC_NORMAL, gcTimer=@0x7fff5fbff520) at js/src/jsgc.cpp:2384
#10 GCCycle (cx=0x100b016b0, comp=0x0, gckind=GC_NORMAL, gcTimer=@0x7fff5fbff520) at js/src/jsgc.cpp:2679
#11 js_GC (cx=0x100b016b0, comp=0x0, gckind=GC_NORMAL) at js/src/jsgc.cpp:2744
#12 js_DestroyContext (cx=0x100b016b0, mode=JSDCM_FORCE_GC) at js/src/jscntxt.cpp:642
#13 JS_DestroyContext (cx=0x100b016b0) at js/src/jsapi.cpp:1040
#14 DestroyContext (cx=0x100b016b0, withGC=true) at js/src/shell/js.cpp:5974
#15 main (argc=4, argv=0x7fff5fbff6e0, envp=0x7fff5fbff708) at js/src/shell/js.cpp:6230

We assert that you don't destroy the last context during GC. The easiest workaround I can think of is for the shell (and all ctypes-using JSAPI applications) to keep an extra cx around until we're pretty sure all objects have been finalized.

That's kind of gross, though. Anyone got alternatives?
Blocks: 666929
While whatever ctypes-knowing person is solving this, I have a related question: what is the multi-threading situation with ctypes that requires a JS_SetContextThread/JS_ClearContextThread in ClosureStub?
There's some sort of multithreaded callback support.
Do you see a straight-forward way to handle this in a single-threaded runtime world?
Why is that assert useful? It just seems incorrect.
Hey all:

I just hit this with a js-ctypes backed add-on I'm developing for Thunderbird.  Just thought I'd let y'all know.

Ouch, this bites the new worker stuff too if you use ctypes. dmandelin, can we get this assigned?
I will look into it.
Assignee: nobody → igor
Blocks: 671027
Depends on: 737364

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: igor → nobody

not reproducible on latest m-c.
possibly related to bug 675078

Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.