4

I'm trying to use libmozjs (SpiderMonkey) under Linux x64 (Ubuntu 17.04). However, something goes wrong at the very first steps.

The SpiderMonkey project has no bug tracker, also after using Google very hard I didn't find any workaround about my problem, so I ask the honoured StackOverflow's community for help.

First of all, I tried this with 3 versions of SpiderMonkey:

  1. Version 45 (stable): https://people.mozilla.org/~sfink/mozjs-45.0.2.tar.bz2
  2. Version 52 (draft): https://hg.mozilla.org/releases/mozilla-esr52/archive/tip.tar.bz2
  3. Version 55a1 (draft, latest): hg clone http://hg.mozilla.org/mozilla-central/

Second, all these versions were made by the same way:

$ cd js/src
$ autoconf2.13
$ mkdir build_DBG.OBJ
$ cd build_DBG.OBJ
$ ../configure --enable-debug --disable-optimize
$ make

(Initially I used configure without options --enable-debug --disable-optimize, having the same error, later added the options to be able to backtrace the code)

Third, my sample code is extremely simple:

#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;
}

I have compiled three executables from this code, one for each version of SpiderMonkey:

$ g++ --std=c++11 -I~/mozjs-45/js/src/build_OPT.OBJ/dist/include -L~/mozjs-45/js/src/build_OPT.OBJ/dist/bin test.cpp -o test.45 -Wall -lmozjs-45 -DDEBUG -ggdb

$ g++ --std=c++11 -I~/mozjs-52/js/src/build_OPT.OBJ/dist/include -L~/mozjs-52/js/src/build_OPT.OBJ/dist/bin test.cpp -o test.52 -Wall -lmozjs-52 -DDEBUG -ggdb

$ g++ --std=c++11 -I~/mozjs-55a1/js/src/build_OPT.OBJ/dist/include -L~/mozjs-55a1/js/src/build_OPT.OBJ/dist/bin test.cpp -o test.55a1 -Wall -lmozjs-55a1 -DDEBUG -ggdb

And finally, the result:

Version 45

As expected:

$ ./test.45
Start...
It's alive!
Finished

Version 52

Error while calling JS_Init:

$ ./test.52
Start...

Segmentation fault (core dumped)

Version 55a1

Error before calling JS_Init:

$ ./test.55a1

Segmentation fault (core dumped)

Backtrace of ./test.52

Starting program: /home/tumick/C/cpp/test.52 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff5c27dfa in JS::detail::InitWithFailureDiagnostic (isDebugBuild=true)
    at /home/tumick/mozilla-esr52-patched/js/src/vm/Initialization.cpp:89
#2  0x000055555555501a in JS_Init ()
    at /home/tumick/mozilla-esr52-patched/js/src/build_DBG.OBJ/dist/include/js/Initialization.h:68
#3  0x0000555555554e38 in main (argc=1, args=0x7fffffffe078) at test.cpp:9

Backtrace of ./test.55a1

Starting program: /home/tumick/C/cpp/test.55a1 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff5d8d02c in js::Mutex::Mutex (this=0x7ffff7dcc000 <js::vtune::VTuneMutex>, id=...)
    at /home/tumick/mozilla-central/js/src/threading/Mutex.h:57
#2  0x00007ffff5d9a1e3 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
    at /home/tumick/mozilla-central/js/src/vtune/VTuneWrapper.cpp:26
#3  0x00007ffff5d9a213 in _GLOBAL__sub_I_VTuneWrapper.cpp(void) ()
    at /home/tumick/mozilla-central/js/src/vtune/VTuneWrapper.cpp:181
#4  0x00007ffff7de781a in call_init (l=<optimized out>, argc=argc@entry=1, 
    argv=argv@entry=0x7fffffffe078, env=env@entry=0x7fffffffe088) at dl-init.c:72
#5  0x00007ffff7de792b in call_init (env=0x7fffffffe088, argv=0x7fffffffe078, argc=1, l=<optimized out>)
    at dl-init.c:30
#6  _dl_init (main_map=0x7ffff7ffe168, argc=1, argv=0x7fffffffe078, env=0x7fffffffe088) at dl-init.c:120
#7  0x00007ffff7dd7cda in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#8  0x0000000000000001 in ?? ()
#9  0x00007fffffffe3b8 in ?? ()
#10 0x0000000000000000 in ?? ()

Yes I know, version 45 is the latest that has been officially released. But first, Mozilla Firefox itself use each new version of SpiderMonkey just after it is complete. And second, we use version 52 on Windows (both 32- and 64-bit) for months in very highloaded environment, build from the same sources, without any problems.

Version 52 has a couple of key features, because of what we have to use exactly version 52 or later.

Finally, I should admit, I'm not very experienced neither with C++, nor with Linux. Considering the problem arises at such a first step and with such a trivial code, I suppose that I've just overlooked something very basic and simple.

So, if You've meet the same problem and know the workaround to solve it, please, help me to deal with it.

Thank You :)

tumick
  • 105
  • 5
  • Important notice: after `make` libmozjs (all of three versions) I first made sure that it works correct, running `./build_DBG.OBJ/js/src/jsapi-tests/jsapi-tests`. All tests were successfull. – tumick Jun 03 '17 at 20:19
  • `$ uname -r` 4.10.0-20-generic `$ gcc --version` gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406 `$ ld --version` GNU lg (GNU Binutils for Ubuntu) 2.28 – tumick Jun 03 '17 at 20:27
  • Have tried with option `--disable-jemalloc` - same result – tumick Jun 12 '17 at 09:30

2 Answers2

2

I had the same issue with 59a1. Only way to prevent core dump was the use the expandlibs.py tool gecko-dev uses. I also supplied supplied the same g++ options used to link gecko-dev.

In my 59a1 build_OPT.OBJ directory I did:

./_virtualenv/bin/python ../../../config/expandlibs_exec.py --uselist
--  /usr/bin/g++ -std=gnu++14 -o js-test $(pkg-config --libs mozjs-59a1) $(pkg-config --cflags mozjs-59a1) -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-security -fno-sized-deallocation -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -O3 -fno-omit-frame-pointer test.cpp -lpthread -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,--build-id -B /home/plm/Source/gecko-dev/js/src/build_OPT.OBJ/build/unix/gold -rdynamic -Wl,-rpath-link,/home/plm/Source/gecko-dev/js/src/build_OPT.OBJ/dist/bin
-Wl,-rpath-link,/usr/local/lib  ./mozglue/build/libmozglue.a ./js/src/build/libjs_static.a -lm -ldl  -lz -lm -ldl
Vega
  • 27,856
  • 27
  • 95
  • 103
Paul LM.
  • 21
  • 2
  • 2
    The important parts of this command line that make it work are the expandlibs program and the linking of ./mozglue/build/libmozglue.a. that program takes libmozglue and extracts the names of a bunch of object files and then adds those files to the link. – ltc Feb 01 '18 at 00:12
2

This is probably caused by https://bugzilla.mozilla.org/show_bug.cgi?id=1176787, and the fix can be found as part of the 60.0a1 milestone.

https://bug1176787.bmoattachments.org/attachment.cgi?id=8884708 should fix your issue when using with mozjs52.

Main reason is that MOZ_GLUE_IN_PROGRAM should be disabled when building in standalone, which is why it also works when linking ./mozglue/build/libmozglue.a

rsalveti
  • 21
  • 1
  • Used SM52: http://ftp.mozilla.org/pub/spidermonkey/prereleases/52/pre1/ Applied the patch listed above and everything started working for me. – dmitri Oct 30 '18 at 03:14