GNOME Bugzilla – Bug 779918
gjs crashed with SIGSEGV in gjs_object_from_g_object
Last modified: 2017-03-29 04:23:13 UTC
Meh, turns out I was wrong and silencing the warning in bug #779871 didn't fix the testcase. It just silenced the warning, and I didn't notice that it was crashing because it didn't print any output. This only seems to happen in a chroot(?) - jhbuild make check in libsecret works fine... That's annoying, because the package builds and the CI tests happen in chroots :( Maybe you can understand this trace. I'm running gjs 1.47.91 + the patch from the bug, and testing libsecret 0.18.5. The test file in question is https://git.gnome.org/browse/libsecret/tree/libsecret/test-js-store.js - AFAICS the crash happens in the anonymous callback in password_store (). root@autopkgtest-lxd-theaqj:/tmp/autopkgtest.rLHBf1/build.5ui/libsecret-0.18.5# LD_LIBRARY_PATH=.libs/ GI_TYPELIB_PATH=$(pwd) dbus-run-session -- gdb --args gjs libsecret/test-js-store.js […] Reading symbols from gjs...Reading symbols from /usr/lib/debug/.build-id/d2/14e5c0c36baf0d24d26c3711e44d97c77cb718.debug...done. done. (gdb) run Starting program: /usr/bin/gjs libsecret/test-js-store.js […] Thread 1 "gjs" received signal SIGSEGV, Segmentation fault. 0x00007ffff47a6f30 in JS_GetClass(JSObject*) () from /usr/lib/x86_64-linux-gnu/libjs.so.0 (gdb) bt
+ Trace 237243
I can't reproduce this on my setup either. If you can garner a bit more information from the backtrace, that would be helpful: - In frame 3, what are the values of i, n_jsargs and n_args? - In frame 1, what are the values of proto and gtype? (use g_type_name() to get a human readable value for gtype) - In frame 1, if proto is NULL which I expect it is, how did it get that way? Could you step through the call to gjs_lookup_object_prototype() from a few lines before the crash and see why it returned NULL? (Using rr instead of gdb may be helpful for this)
Created attachment 347905 [details] bt full Sure, I will do. I assumed (:P) that you're on Fedora, so I tried to reproduce the failure there... here we go. This is using f25 via lxd from my Ubuntu system, but should be the same in a chroot or cloud instance or any other minimal thing. # dnf install git make automake gcc gcc-c++ mozjs38-devel redhat-rpm-config python3-dbus python3-gobject # dnf builddep gjs libsecret # git clone git://git.gnome.org/gjs.git # cd gjs; ./autogen.sh CFLAGS="-g -O0" CXXFLAGS="-g -O0"; make # cd ..; git clone git://git.gnome.org/libsecret.git; cd libsecret; ./autogen.sh; make # LD_LIBRARY_PATH=.libs/ GI_TYPELIB_PATH=$(pwd) dbus-run-session -- ../gjs/gjs-console libsecret/test-js-store.js It doesn't print anything (so it looks like it succeeds!), but if you # echo $? 139 it crashed! So let's run under gdb (still on Fedora) and get what you asked for # LD_LIBRARY_PATH=.libs/ GI_TYPELIB_PATH=$(pwd) dbus-run-session -- ../gjs/libtool --mode=execute gdb --args ../gjs/gjs-console libsecret/test-js-store.j (gdb) frame 1 #1 0x00007ffff7b1077f in gjs_object_from_g_object (context=0x655050, gobj=0x62c900 [GSimpleAsyncResult]) at gi/object.cpp:2197 2197 global)); (gdb) print proto $1 = {<js::RootedBase<JSObject*>> = {<No data fields>}, stack = 0x655068, prev = 0x7fffffffc520, ptr = 0x0} (gdb) print g_type_name (gtype) [Thread 0x7fffe99aa700 (LWP 2881) exited] $2 = (const gchar *) 0x7ffff58f3440 "GSimpleAsyncResult" (gdb) frame 3 #3 0x00007ffff7affa14 in gjs_callback_closure (cif=0x7663c8, result=0x7fffffffc960, args=0x7fffffffc7c0, data=0x766380) at gi/function.cpp:264 264 if (!gjs_value_from_g_argument(context, jsargs[n_jsargs++], (gdb) print i $3 = 1 (gdb) print n_args $4 = 3 (gdb) print n_jsargs $5 = 2 (gdb) and I'll attach a `bt full' too. I'm not too sure what to do with proto in frame 1. proto.ptr is NULL; is that what you mean? Looking at gjs_lookup_object_prototype, it returns the following (gdb) print *gjs_lookup_object_prototype (context, gtype) $1 = {<js::gc::Cell> = {<No data fields>}, shape_ = {<js::BarrieredBase<js::Shape*>> = {<js::BarrieredBaseMixins<js::Shape*>> = {<No data fields>}, value = 0x7fffea66cc40}, <No data fields>}, group_ = {<js::BarrieredBase<js::ObjectGroup*>> = {<js::BarrieredBaseMixins<js::ObjectGroup*>> = {<No data fields>}, value = 0x7fffea69a640}, <No data fields>}, static MaxTagBits = 3, static ITER_CLASS_NFIXED_SLOTS = 1, static MAX_BYTE_SIZE = 160} Hope this is helpful & you can reproduce with my instructions. Let me know if you want anything more.
Thanks. I'm actually on Endless OS but I was able to reproduce it nonetheless, using uninstalled GJS and libsecret as in your above instructions. So, one problem is the known one of our importer code swallowing exceptions all over the place. I fixed this particular instance and I'll attach a patch for it in a moment. However, that doesn't fix the problem, just allowed me to figure out what was actually going on. The crash is due to not being able to find GJS's internal GjsPrivate typelib. If I replace "GI_TYPELIB_PATH=$(pwd)" with "GI_TYPELIB_PATH=.:../gjs" in the invocation, it doesn't crash for me. Does that work for you as well?
Created attachment 347960 [details] [review] object: Don't crash on error in gjs_object_from_g_object() Fix one spot where we ignore a JS exception from gjs_lookup_object_prototype() which causes a crash later. Also fix another spot where we would crash if JS_NewObjectWithGivenProto() fails, though that is unlikely except on OOM.
Review of attachment 347960 [details] [review]: Makes sense to me.
Aha! That's interesting - turns out my reproducer tickles the same problem in a different way. If I run against an *installed* gjs in a minimal environment, with this patch--- root@autopkgtest-lxd-rnjyjd:/tmp/autopkgtest.J8N01W/build.7RE/libsecret-0.18.5# LD_LIBRARY_PATH=.libs/ GI_TYPELIB_PATH=/usr/lib/gjs/girepository-1.0/:$(pwd) dbus-run-session -- gjs-console libsecret /test-js-store.js (gjs-console:26604): Gjs-WARNING **: JS ERROR: Error: Requiring GjsPrivate, version none: Typelib file for namespace 'Gtk', version '3.0' not found Now it's possible to see that the problem is a missing dependency. :-) Cheers!
OK, thanks. I'll reduce the priority of this accordingly.
Attachment 347960 [details] pushed as 5a45fff - object: Don't crash on error in gjs_object_from_g_object()