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

Status: RESOLVED WORKSFORME

(Core :: js-ctypes, defect)

Description

[Jason Orendorff [:jorendorff]]

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

#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?

Comment 1

[Luke Wagner [:luke]]

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?

Comment 2

[Ben Turner (not reading bugmail, use the needinfo flag!)]

There's some sort of multithreaded callback support.

Comment 3

[Luke Wagner [:luke]]

Do you see a straight-forward way to handle this in a single-threaded runtime world?

Comment 4

[Chris Leary [:cdleary] (not checking bugmail)]

Why is that assert useful? It just seems incorrect.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

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.

-Mike

Comment 6

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Ouch, this bites the new worker stuff too if you use ctypes. dmandelin, can we get this assigned?

Comment 7

[Igor Bukanov]

I will look into it.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 9

[Tooru Fujisawa [:arai]]

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