GNOME Bugzilla – Bug 770244
SEGFAULT in js::NewObjectWithClassProtoCommon when instantiating a dynamic type defined in JS
Last modified: 2016-11-15 23:23:09 UTC
Created attachment 333927 [details] test case gjs segfaults if you try to call g_object_new() on a dynamic type registered in a GjsContext Backtrace: Thread 1 "gjs-test" received signal SIGSEGV, Segmentation fault. 0x00007ffff064b1a6 in js::NewObjectWithClassProtoCommon (cx=0x677800, clasp=0x7ffff0b9fdc0 <js::ObjectClass>, protoArg=0x0, parentArg=0x0, allocKind=js::gc::FINALIZE_OBJECT0_BACKGROUND, newKind=js::GenericObject) at /build/mozjs24-UQFbnn/mozjs24-24.2.0/js/src/jsobj.cpp:1349 1349 /build/mozjs24-UQFbnn/mozjs24-24.2.0/js/src/jsobj.cpp: No such file or directory. (gdb) bt
+ Trace 236571
Created attachment 334397 [details] [review] Add JS defined class object instantiation test A test case that also exposes the crash
Created attachment 339959 [details] [review] object: Enter global compartment in custom constructor Previously you could construct JS-defined GObjects from inside JS, but not from C. That's because when the constructor() vfunc is called from C, the JS engine isn't inside the right compartment. While entering the compartment using JSAutoCompartment, we also change the constructor vfunc to use JSAutoRequest, so that it consistently uses a more RAII style. Test case from commit by Juan Pablo Ugarte <juanpablougarte@gmail.com>
Needs mozjs31 to work. Apparently in mozjs24 the JIT doesn't like this.
Review of attachment 334397 [details] [review]: OK
Comment on attachment 334397 [details] [review] Add JS defined class object instantiation test Actually this is obsolete
Review of attachment 339959 [details] [review]: Looks good to me.
Attachment 339959 [details] pushed as a1e1a80 - object: Enter global compartment in custom constructor
I pushed it to the "mozjs31" branch — it'll be merged to master when we're ready to merge the whole branch.