GNOME Bugzilla – Bug 786490
g-ir-scanner crashes during build with js52
Last modified: 2017-08-25 03:25:06 UTC
Chances are I just have some weird combination of libraries, but apparently I'm not the only one with this issue... While compiling current gjs master against mozjs-52, g-ir-scanner reports a crash: SystemExit: Command '['/…/src/gjs/tmp-introspectqdejaj1u/GjsPrivate-1.0', '--introspect-dump=/…/src/gjs/tmp-introspectqdejaj1u/functions.txt,/…/src/gjs/tmp-introspectqdejaj1u/dump.xml']' died with <Signals.SIGSEGV: 11>. Running …/tmp-introspectqdejaj1u/GjsPrivate-1.0 via gdb shows: (gdb) thread apply all bt full
+ Trace 237813
Thread 1 (Thread 0x7ffff7f699c0 (LWP 117221))
which according to https://dxr.mozilla.org/mozilla-esr52/source/js/src/vm/Initialization.cpp#89 seems to happen very early during init. This is on Arch Linux (using js52 from AUR), but according to people on IRC, OpenSuSE is also affected. The /usr/bin/js52 program works fine, as does the helloworld example from mozilla. js 52.3.0esr (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=js52)
*** Bug 786475 has been marked as a duplicate of this bug. ***
Just checked, the main "gjs-console" binary also crashes in exactly the same manner. So it's not related to g-ir-scanner.
Trying to build / test a very basic C++ program linking mozjs-52 already crashes here: > cat test.cc #include <iostream> #include <stdexcept> #include "jsapi.h" #include "js/Initialization.h" int main(int argc, char** args){ std::cout<< "Start...\n"; if(!JS_Init()) throw std::runtime_error("Failed to initialize"); std::cout << "It's alive!\n"; JS_ShutDown(); std::cout << "Finished\n"; return 0; } > g++ test.cc $(pkg-config --cflags --libs mozjs-52) -o test.bin > ./test.bin Start... Segmentation fault (core dumped) So there is definitively mozjs52 failing
Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt
+ Trace 237815
and Initialization.cpp:89 is about this: // The first invocation of `ProcessCreation` creates a temporary thread // and crashes if that fails, i.e. because we're out of memory. To prevent // that from happening at some later time, get it out of the way during // startup. bool ignored; mozilla::TimeStamp::ProcessCreation(ignored);
(In reply to Dominique Leuenberger from comment #3) > Trying to build / test a very basic C++ program linking mozjs-52 already > crashes here: Can't reproduce here on Arch; pure js52-only programs work fine. But, it complained about missing -lpthread while trying to compile test.cc; apparently that's needed by something called "libmozglue.a". (Which apparently comes from xulrunner 41.0.2 on Arch.) I've no idea if it's related in any way, but it *does* feel suspicious; could there be incompatible versions of js and mozglue, or something?
(In reply to Mantas Mikulėnas (grawity) from comment #5) > But, it complained about missing -lpthread while trying to compile test.cc; > apparently that's needed by something called "libmozglue.a". (Which > apparently comes from xulrunner 41.0.2 on Arch.) > > I've no idea if it's related in any way, but it *does* feel suspicious; > could there be incompatible versions of js and mozglue, or something? Seems to be your own patch: https://aur.archlinux.org/cgit/aur.git/tree/link-mozglue.patch?h=js52 - we don't have this here (neither does jhbuild use anything like this)
(In reply to Dominique Leuenberger from comment #3) > Trying to build / test a very basic C++ program linking mozjs-52 already > crashes here: I built mozjs-52 based on the mozjs52 tarball from teams/releng from on download.gnome.org - and that test program now no longer crashes. Also, I was able to build gjs with this version of mozjs52 on openSUSE
Aha, mozglue should not be a shared library (and for that matter, your xulrunner package should probably not export it. I don't think it's meant to be "shared" except between components in the monolithic Firefox build.) I expect the problem comes from using mozglue from mozilla-41 whereas SpiderMonkey 52 needs it from mozilla-52. I assume the Arch patch was added as a fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1176787 ? I'd recommend using my patch instead. Can you confirm that works?
(In reply to Philip Chimento from comment #8) > Aha, mozglue should not be a shared library (and for that matter, your > xulrunner package should probably not export it. I don't think it's meant to > be "shared" except between components in the monolithic Firefox build.) I > expect the problem comes from using mozglue from mozilla-41 whereas > SpiderMonkey 52 needs it from mozilla-52. > > I assume the Arch patch was added as a fix for > https://bugzilla.mozilla.org/show_bug.cgi?id=1176787 ? I'd recommend using > my patch instead. Can you confirm that works? Yes, it compiled successfully; gnome-shell.git seems to be working with it as well.
OK, I'm assuming this can be closed then.
The packager's response at https://aur.archlinux.org/packages/js52/: > I don't think it's a good idea to break jemalloc. For gjs, I've updated link-mozglue.patch so that it can build and run after patching its build system [1] > > [1] https://github.com/yan12125/gjs/commit/d2b083cf3ee74952802f3d8457ee7e24173ba303
I'm afraid I don't understand what they are trying to do, or what user of jemalloc is being broken by that change. mozjs doesn't use jemalloc unless you enable some flag (which I've never tested, so I wouldn't recommend it.) In any case, I don't think that patch for GJS is correct; gjs-console doesn't use mozjs symbols directly, so shouldn't have to link against mozjs directly. (It would also mean that gnome-shell, sushi, etc. would have to link against mozjs directly.) If the Arch maintainer prefers to do it that way and everything is consistent, it'll probably work out fine, but still a bit inconvenient for me because now when I get crash reports from Arch users I'll have to wonder if it's because it's linking to invalid mozglue...