coredump when loading a dynamic library file.

[dreamyzhang]

• Node.js Version:6.9
• OS:linux
• Scope (install, code, runtime, meta, other?):
• Module (and version) (if relevant):

node will coredump when loading a dynamic library file, and replace with another dynamic library file it will ok. I suspect that it is the problem of memory limit for v8, but not sure and how to solve this problem? the dynamic library file can work well in the binary program of c++.

[ops@smartwindev node-ctp]$ node  --trace_gc -e  ./tduser.js 
[18751:0x3b59730]        8 ms: Scavenge 2.1 (37.0) -> 2.0 (37.0) MB, 0.7 / 0 ms [allocation failure].
[18751:0x3b59730]        9 ms: Scavenge 2.1 (37.0) -> 2.1 (38.0) MB, 0.7 / 0 ms [allocation failure].
[eval]:1
./tduser.js
^
SyntaxError: Unexpected token .
    at Object.exports.runInThisContext (vm.js:76:16)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (module.js:556:32)
    at bootstrap_node.js:357:29
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)


strace node tduser.js  
lstat("/home/ops/dreamy/node-ctp", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat("/home/ops/dreamy/node-ctp/build", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat("/home/ops/dreamy/node-ctp/build/Release", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat("/home/ops/dreamy/node-ctp/build/Release/shifctp.node", {st_mode=S_IFREG|0775, st_size=73608, ...}) = 0
clock_gettime(CLOCK_MONOTONIC, {779141, 167992244}) = 0
clock_gettime(CLOCK_MONOTONIC, {779141, 168109721}) = 0
futex(0x7f41f6dcb0d0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/home/ops/dreamy/node-ctp/build/Release/shifctp.node", O_RDONLY|O_CLOEXEC) = 9
read(9, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260u\0\0\0\0\0\0"..., 832) = 832
fstat(9, {st_mode=S_IFREG|0775, st_size=73608, ...}) = 0
mmap(NULL, 2146904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 9, 0) = 0x7f41f39b1000
mprotect(0x7f41f39bc000, 2097152, PROT_NONE) = 0
mmap(0x7f41f3bbc000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 9, 0xb000) = 0x7f41f3bbc000
close(9)                                = 0
open("/home/ops/dreamy/node-ctp/linux_api_trade_6.3.6/thosttraderapi.so", O_RDONLY|O_CLOEXEC) = 9
read(9, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0K\20\0\0\0\0\0"..., 832) = 832
fstat(9, {st_mode=S_IFREG|0755, st_size=4281233, ...}) = 0
mmap(NULL, 8168840, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 9, 0) = 0x7f41f31e6000
mprotect(0x7f41f3518000, 2093056, PROT_NONE) = 0
mmap(0x7f41f3717000, 282624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 9, 0x331000) = 0x7f41f3717000
mmap(0x7f41f375c000, 2442632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f41f375c000
close(9)                                = 0
mprotect(0x7f41f3bbc000, 4096, PROT_READ) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7f41f34aae0e} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault

[bnoordhuis]

Easy enough to find out. Execute gdb --args node tduser.js, type run, then backtrace full when it segfaults. The backtrace will tell you where it crashes and hopefully also provide a clue as to why it crashes.

[dreamyzhang]

Program received signal SIGSEGV, Segmentation fault.
0x000000000093e9b5 in OPENSSL_ia32_cpuid ()
Missing separate debuginfos, use: debuginfo-install glibc-2.17-106.el7_2.8.x86_64 glibc-2.17-157.el7_3.1.x86_64 libgcc-4.8.5-11.el7.x86_64 libgcc-4.8.5-4.el7.x86_64 libstdc++-4.8.5-11.el7.x86_64 libstdc++-4.8.5-4.el7.x86_64
(gdb)
(gdb) bt
#0 0x000000000093e9b5 in OPENSSL_ia32_cpuid ()
#1 0x00007fffefa2b9d6 in OPENSSL_cpuid_setup () from /home/ops/dreamy/node-ctp/linux_api_trade_6.3.6/thosttraderapi.so
#2 0x00007fffef92d6c3 in _init () from /home/ops/dreamy/node-ctp/linux_api_trade_6.3.6/thosttraderapi.so
#3 0x00007ffff49844d0 in ?? () from /home/ops/dreamy/node-ctp/build/Release/shifctp.node
#4 0x00007ffff7dec19f in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff7df08f6 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#6 0x00007ffff7debff4 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#7 0x00007ffff7deffeb in _dl_open () from /lib64/ld-linux-x86-64.so.2
#8 0x00007ffff7bd9fbb in dlopen_doit () from /lib64/libdl.so.2
#9 0x00007ffff7debff4 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#10 0x00007ffff7bda5bd in _dlerror_run () from /lib64/libdl.so.2
#11 0x00007ffff7bda051 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2
#12 0x000000000122f297 in uv_dlopen (filename=0x7fffffffcb90 "/home/ops/dreamy/node-ctp/build/Release/shifctp.node",
lib=0x7fffffffc750) at ../deps/uv/src/unix/dl.c:36
#13 0x0000000000fb9987 in node::DLOpen(v8::FunctionCallbackInfov8::Value const&) ()
#14 0x0000000000986381 in v8::internal::FunctionCallbackArguments::Call(void ()(v8::FunctionCallbackInfov8::Value const&)) ()
#15 0x00000000009da80b in v8::internal::MaybeHandlev8::internal::Object v8::internal::(anonymous namespace)::HandleApiCallHelper(v8::internal::Isolate, v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>)
()
#16 0x00000000009dadb1 in v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) ()

It work well when run with root privileges. on the other uses will coredump.

[dreamyzhang]

and the dynamic library file can work well in the binary program of c++.

[bnoordhuis]

Can you continue after that SIGSEGV? OPENSSL_ia32_cpuid() sniffs for CPU features, the signal may be handled by a signal handler it installs.

What version of openssl does thosttraderapi.so expect? Node bundles its own copy of openssl, which is probably different (newer) than the one installed on your system. You probably want to link or dlopen() it in a way that it loads libcrypto.so and/or libssl.so from your system instead of from node.

[dreamyzhang]

The problem is resolved. the reason is that install the node environment by NVM under the ordinary users and the node environment is another under the root user in /usr/bin.
only using NVM to install node will have this problem, and try the other node versions installed by NVM all will be wrong.

[bnoordhuis]

Happy to hear it's working for you now. I'll close out the issue.