Linux x64でlibmozjs-52（SpiderMonkey）を使用したセグメント化エラー

Question

Linux x64（Ubuntu 17.04）でlibmozjs（SpiderMonkey）を使用しようとしています。しかし、最初のステップでは何かが間違っています。

SpiderMonkeyプロジェクトにはバグトラッカーがありません.Googleを使用した後も、私の問題については回避策が見つかりませんでしたので、敬意を表するStackOverflowのコミュニティにお問い合わせください。

1. バージョン45（安定的）：https://people.mozilla.org/~sfink/mozjs-45.0.2.tar.bz2
2. バージョン52（ドラフト）：https://hg.mozilla.org/releases/mozilla-esr52/archive/tip.tar.bz2
3. バージョン55a1（ドラフト、最新の）

   まず第一に、私はSpiderMonkeyのの3つのバージョンでこれを試してみました：

   ：hg clone http://hg.mozilla.org/mozilla-central/

第二に、すべてのこれらのバージョンは、同じ方法で作られました

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

（当初、私は同じエラーを持つ、オプション--enable-debug --disable-optimizeなしconfigureを使用し、後でコードをバックトレースできるようにするオプションを追加しました）

第三に、私のサンプルコードは非常に簡単です：

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

私はSpiderMonkeyののバージョンごとに、このコード、1から3つの実行可能ファイルをコンパイルしている：

$ 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 

A最終的にはND、結果：予想通り

バージョン45

：

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

バージョン52

エラーJS_Initの呼び出し中：

$ ./test.52 
Start... 

Segmentation fault (core dumped) 

バージョンJS_Initを呼び出す前55a1

エラー：

$ ./test.55a1 

Segmentation fault (core dumped) 

./test.55a1

の./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 

バックトレースのバックトレース

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 ??() 

はい、私は知っています、バージョン45は正式にリリースされた最新です。しかし、最初に、Mozilla Firefox自体が完成した直後に、新しいバージョンのSpiderMonkeyをそれぞれ使用します。次に、非常に負荷の高い環境で数か月間、Windows上でバージョン52（32ビットと64ビットの両方）を使用し、問題なく同じソースからビルドします。

バージョン52には、バージョン52以降のバージョンを使用する必要があるため、いくつかの重要な機能があります。

最後に、私はC++やLinuxで経験したことはありません。このような最初のステップで問題が発生し、そのような簡単なコードがあることを考えれば、私は非常に基本的で単純なものを見過ごしたと思います。

あなたが同じ問題を抱えており、それを解決するための回避策を知っているなら、それに対処するのを手伝ってください。

ありがとうございました:)

Answer 1

私は59a1と同じ問題がありました。コアダンプを防止する唯一の方法は、gecko-devが使用するexpandlibs.pyツールを使用することでした。私はgecko-devとリンクするのに使用されたg ++オプションも提供しました。

./_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