GNOME Bugzilla – Bug 786578
gnome-shell unit test failures on armhf with gjs 1.49/mozjs52
Last modified: 2017-08-30 08:13:50 UTC
gjs 1.49.90 gnome-shell 3.24.3 with some commits backported so that gnome-shell will run with gjs 1.49/mozjs52. Since I'm not sure how much Mozilla cares about armhf (Firefox fails to build on armhf on Ubuntu since Firefox 51 I believe), I intend to set gnome-shell's tests to not fail the build on armhf on Ubuntu. https://launchpad.net/ubuntu/+source/gnome-shell/3.24.3-0ubuntu5/+build/13277002 Build log excerpt ================= ok 23 Introspected GObject has normal Object methods not ok 24 Introspected GObject resolves properties when they are shadowed by methods # Message: Expected undefined to equal 42. # Stack: # @/usr/lib/gjs/gjs/installed-tests/js/testEverythingEncapsulated.js:241:9 JS G OBJ: Defining method set_bare in prototype for RegressTestObj (Regress.TestObj)
I think you pasted the build log from the other bug you opened recently. This seems to be the only problem I can find in the build log: GSETTINGS_SCHEMA_DIR=data xvfb-run tests/run-test.sh -v tests/unit/*.js JS NATIVE: Registered native JS module 'byteArray' JS NATIVE: Registered native JS module '_gi' JS NATIVE: Registered native JS module 'gi' JS NATIVE: Registered native JS module 'cairoNative' JS NATIVE: Registered native JS module 'system' JS NATIVE: Registered native JS module 'console' Assertion failure: !joinable(), at /build/mozjs52-AmEQse/mozjs52-52.2.1/js/src/threading/Thread.h:122 Segmentation fault (core dumped) Is it possible to get a stack trace, or check if mozjs's "js52" binary works properly? I do have an armhf system on which I can check, eventually, but if there's some way to get the info from Ubuntu's build that would be better, since it'll take a dog's age to compile mozjs on my armhf system.
Hey Philip! I logged onto an armhf machine and got a trace of just running `gjs'. Our mozjs package removes /usr/bin/js52 for some reason - I'm building a version with it and I'll post again tomorrow when it's available. Hope this is useful. (gdb) run Starting program: /usr/bin/gjs [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". [New Thread 0xf49f11f0 (LWP 4456)] [Thread 0xf49f11f0 (LWP 4456) exited] Thread 1 "gjs" received signal SIGSEGV, Segmentation fault. js::Thread::~Thread (this=<optimized out>, __in_chrg=<optimized out>) at ./js/src/threading/Thread.h:122 (gdb) bt full
+ Trace 237844
Thanks Iain. I dropped /usr/bin/js* from the Debian/Ubuntu packaging because that was recommended by Mike Homney at https://bugzilla.mozilla.org/show_bug.cgi?id=1339931#c9
(In reply to Jeremy Bicha from comment #3) > I dropped /usr/bin/js* from the Debian/Ubuntu packaging because that was > recommended by Mike Homney at > https://bugzilla.mozilla.org/show_bug.cgi?id=1339931#c9 No worries, thanks for the pointer. It's only a 30 minute build. :) So: root@autopkgtest-lxd-xuazme:/tmp/autopkgtest.4UgTRO/build.yXW/gjs-1.49.91# js52 js> console.log('hello') hello js> 1+3 4 js> function foo() { print('bar') } js> foo() bar ...should I try to do something more complex?
Thanks. The assertion seems to be happening here: https://dxr.mozilla.org/mozilla-esr52/source/js/src/vm/HelperThreads.cpp?q=HelperThreads.cpp&redirect_type=direct#721 My guess would be that the destructor of the Thread instance is running too early, maybe they need a std::move() in there? I'm not sure. Arch / OpenSUSE recently ran into problems with initializing threading because they were linking to a random mozglue library provided by another component on the system. Perhaps your package is doing the same? I recommend using my patch on https://bugzilla.mozilla.org/show_bug.cgi?id=1176787 to make sure to compile the correct mozglue directly into mozjs. (In reply to Jeremy Bicha from comment #3) > I dropped /usr/bin/js* from the Debian/Ubuntu packaging because that was > recommended by Mike Homney at > https://bugzilla.mozilla.org/show_bug.cgi?id=1339931#c9 As an aside, Steve Fink nuanced this later in the comment thread and now I'd recommend putting /usr/bin/js52 in the -dev package: https://bugzilla.mozilla.org/show_bug.cgi?id=1339931#c22
By the way, I didn't push the --enable-posix-nspr-emulation change to Ubuntu yet. Do you think that would help here? https://anonscm.debian.org/git/pkg-gnome/mozjs52.git/commit/?id=093740f
I doubt it, it doesn't look like the crashing section of the code uses NSPR, but you never know. I would recommend doing it anyway, because the NSPR dependency is totally unnecessary.
Ok, actually, this happens when I hit ctrl-d in the js52 REPL (gdb) set pagination 0 (gdb) run Starting program: /usr/bin/js52 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". [New Thread 0xf71b5450 (LWP 9765)] [Thread 0xf71b5450 (LWP 9765) exited] [New Thread 0xf71b5450 (LWP 9766)] [New Thread 0xf67ff450 (LWP 9767)] [New Thread 0xf5fff450 (LWP 9768)] [New Thread 0xf57ff450 (LWP 9769)] [New Thread 0xf4fff450 (LWP 9770)] [New Thread 0xf47ff450 (LWP 9771)] [New Thread 0xf3fff450 (LWP 9772)] [New Thread 0xf37ff450 (LWP 9773)] js> [Thread 0xf71b5450 (LWP 9766) exited] Thread 1 "js52" received signal SIGSEGV, Segmentation fault. js::Thread::~Thread (this=0xabe292d0, __in_chrg=<optimized out>) at ./js/src/threading/Thread.h:122 (gdb) bt full
+ Trace 237863
Still in the destructor. Don't know if that sheds any light or not.
No, but it means we should probably report a bug to Mozilla :-) One potentially useful thing you could do is examine the Thread data structure in GDB and see if the state is just incorrect (indicating a logic error) or garbage (indicating memory corruption). I'll see if I get any different results on my ARM machine.
On my armhf machine I compiled ftp://ftp.gnome.org/pub/gnome/teams/releng/tarballs-needing-help/mozjs/mozjs-52.2.1gnome1.tar.gz in a sandbox of org.gnome.Sdk//master from gnome-nightly, using "--enable-posix-nspr-emulation --with-system-zlib --with-intl-api AUTOCONF=autoconf" as the configure options. The js52 REPL worked fine for me, so it might be the patches you've applied or the configure options?
I updated Ubuntu's mozjs52 to the latest treeherder tarball (August 8). The -dev package now installs /usr/bin/js52. Configure flags at: https://anonscm.debian.org/git/pkg-gnome/mozjs52.git/tree/debian/rules Patches are at: https://anonscm.debian.org/git/pkg-gnome/mozjs52.git/tree/debian/patches (If you look in series, you'll see that 3 patches are commented out since they don't apply but they were only for obscure non-Ubuntu architectures any way). I believe it now includes all the patches from https://github.com/ptomato/mozjs/commits/mozjs52 except the OS X patch and the README patch. I had to build --with-system-nspr because --enable-posix-nspr-emulation didn't work. See bug 786834. The armhf autopkgtest still fails: http://autopkgtest.ubuntu.com/packages/g/gjs/artful/armhf
Does js52 still crash on exit?
(In reply to Philip Chimento from comment #12) > Does js52 still crash on exit? Yeah. I built the tarball as in #10 - same tarball, same configure options as you, no patches, and it crashes the same. Same for ESR52. Found a related upstream bug and commented there. https://bugzilla.mozilla.org/show_bug.cgi?id=1333340
I meant to write: (In reply to Iain Lane from comment #13) > Same for ESR52. ^ tip (52dc0f52595d).
I guess the workaround would be to use the MOZ_OPTIMIZE_FLAGS from https://bugzilla.mozilla.org/show_bug.cgi?id=1337263 ? I'll cc myself over there and possibly patch that in the GNOME build, depending on what they say.
Right, I ran the testsuite of an upstream build with that in the MOZ_OPTIMIZE_FLAGS and it passed, so I'll try a package build now. Thanks for your help!