【问题标题】:Segmentation Fault using libmozjs-52 (SpiderMonkey) under Linux x64Linux x64 下使用 libmozjs-52 (SpiderMonkey) 的分段错误
【发布时间】:2017-11-04 23:58:06
【问题描述】:

我正在尝试在 Linux x64 (Ubuntu 17.04) 下使用 libmozjs (SpiderMonkey)。但是,在最初的步骤中出现了问题。

SpiderMonkey 项目没有错误跟踪器,而且在非常努力地使用 Google 之后,我也没有找到任何解决我的问题的方法,所以我向尊敬的 StackOverflow 社区寻求帮助。

首先,我尝试了 3 个版本的 SpiderMonkey:

  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(草稿,最新):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

(一开始我用configure不带选项--enable-debug --disable-optimize,报同样的错误,后来加了选项可以回溯代码)

第三,我的示例代码非常简单:

#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 一个:

$ 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

最后,结果:

版本 45

如预期:

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

版本 52

调用JS_Init时出错:

$ ./test.52
Start...

Segmentation fault (core dumped)

版本 55a1

错误之前调用JS_Init

$ ./test.55a1

Segmentation fault (core dumped)

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

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

是的,我知道,45 版是正式发布的最新版本。但首先,Mozilla Firefox 本身会在每个新版本的 SpiderMonkey 完成后使用它。其次,我们在 Windows(32 位和 64 位)上使用 52 版本,在负载非常高的环境中使用了几个月,从相同的源构建,没有任何问题。

版本 52 有几个关键特性,因为我们必须完全使用版本 52 或更高版本。

最后,我应该承认,我对 C++ 和 Linux 都不是很有经验。考虑到问题出现在这样的第一步和如此琐碎的代码中,我想我只是忽略了一些非常基本和简单的东西。

所以,如果您遇到同样的问题并且知道解决方法,请帮我解决它。

谢谢你:)

【问题讨论】:

  • 重要提示:在make libmozjs(所有三个版本)之后,我首先确保它工作正常,运行./build_DBG.OBJ/js/src/jsapi-tests/jsapi-tests。所有测试都成功了。
  • $ 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
  • 已尝试使用选项--disable-jemalloc - 结果相同

标签: c++ linux 64-bit segmentation-fault spidermonkey


【解决方案1】:

我对 59a1 也有同样的问题。防止核心转储的唯一方法是使用 expandlibs.py 工具 gecko-dev 使用。我还提供了用于链接 gecko-dev 的相同 g++ 选项。

在我的 59a1 build_OPT.OBJ 目录中我做了:

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

【讨论】:

  • 这个命令行使它工作的重要部分是expandlibs程序和./mozglue/build/libmozglue.a的链接。该程序使用 libmozglue 并提取一堆目标文件的名称,然后将这些文件添加到链接中。
【解决方案2】:

这可能是由https://bugzilla.mozilla.org/show_bug.cgi?id=1176787 引起的,可以在 60.0a1 里程碑中找到修复程序。

https://bug1176787.bmoattachments.org/attachment.cgi?id=8884708 应该可以解决您与 mozjs52 一起使用时的问题。

主要原因是 MOZ_GLUE_IN_PROGRAM 在独立构建时应该被禁用,这就是为什么它在链接 ./mozglue/build/libmozglue.a 时也可以工作

【讨论】:

猜你喜欢
  • 2017-11-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-01-23
  • 1970-01-01
  • 2014-03-17
  • 1970-01-01
相关资源
最近更新 更多