8000 Clang/llvm segfaults when using multiple C++ addons (was: error when using with websockets) · Issue #259 · lovell/sharp · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Clang/llvm segfaults when using multiple C++ addons (was: error when using with websockets) #259

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
aeosynth opened this issue Aug 26, 2015 · 11 comments
Closed

Clang/llvm segfaults when using multiple C++ addons (was: error when using with websockets) #259

aeosynth opened this issue Aug 26, 2015 · 11 comments
Labels
bug
Milestone
v0.11.2

Comments

@aeosynth
Copy link

app.js:

require('ws')
require('sharp')

$ node app.js 
fish: 'node app.js' terminated by signal SIGSEGV (Address boundary error)

websockets/ws also recently added support for iojs v3

edit: this is using sharp master
@lovell
Copy link
Owner
lovell commented Aug 26, 2015

Hi James, are you using gcc 4.9? This might be related to a problem with the use of -O3 in the bufferutil dependency of ws - see websockets/bufferutil#1

@lovell lovell added the triage label Aug 26, 2015
@aeosynth
Copy link
Author

i'm on osx 10.9.5, and my gcc is llvm 6.0. removing the bufferutil dependency does not help.

@lovell
Copy link
Owner
lovell commented Aug 26, 2015

I've not be able to reproduce this locally on Linux with io.js v3.2.0 and compiling with gcc 5.1. I'll try to run a similar test using a Mac tomorrow.

Given you're using llvm, are you able to run the app that segfaults via its lldb debugging tool and get a backtrace?

@aeosynth
Copy link
Author

i've never used lldb before, but here's the trace:

$ lldb node app.js 
(lldb) target create "node"
Current executable set to 'node' (x86_64).
(lldb) settings set -- target.run-args  "app.js"
(lldb) run
Process 75395 launched: '/usr/local/bin/node' (x86_64)
Process 75395 stopped
* thread #1: tid = 0x6296a, 0x00000001017dcf96 sharp.node`Nan::imp::FunctionWrapper* Nan::imp::GetWrapper<void (*)(Nan::FunctionCallbackInfo<v8::Value> const&), Nan::imp::FunctionWrapper>(void (*)(Nan::FunctionCallbackInfo<v8::Value> const&)) [inlined] std::__1::__tree<std::__1::__value_type<void (__parent=<unavailable>, __child=0x00000001017c82c8, __new_node=0x00000001016422f0)(Nan::FunctionCallbackInfo<v8::Value> const&), Nan::imp::FunctionWrapper*>, std::__1::__map_value_compare<void (*)(Nan::FunctionCallbackInfo<v8::Value> const&), std::__1::__value_type<void (*)(Nan::FunctionCallbackInfo<v8::Value> const&), Nan::imp::FunctionWrapper*>, std::__1::less<void (*)(Nan::FunctionCallbackInfo<v8::Value> const&)>, true>, std::__1::allocator<std::__1::__value_type<void (*)(Nan::FunctionCallbackInfo<v8::Value> const&), Nan::imp::FunctionWrapper*> > >::__insert_node_at(std::__1::__tree_node_base<void*>*, std::__1::__tree_node_base<void*>*&, std::__1::__tree_node_base<void*>*) + 25 at __tree:1715, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000001017dcf96 sharp.node`Nan::imp::FunctionWrapper* Nan::imp::GetWrapper<void (*)(Nan::FunctionCallbackInfo<v8::Value> const&), Nan::imp::FunctionWrapper>(void (*)(Nan::FunctionCallbackInfo<v8::Value> const&)) [inlined] std::__1::__tree<std::__1::__value_type<void (__parent=<unavailable>, __child=0x00000001017c82c8, __new_node=0x00000001016422f0)(Nan::FunctionCallbackInfo<v8::Value> const&), Nan::imp::FunctionWrapper*>, std::__1::__map_value_compare<void (*)(Nan::FunctionCallbackInfo<v8::Value> const&), std::__1::__value_type<void (*)(Nan::FunctionCallbackInfo<v8::Value> const&), Nan::imp::FunctionWrapper*>, std::__1::less<void (*)(Nan::FunctionCallbackInfo<v8::Value> const&)>, true>, std::__1::allocator<std::__1::__value_type<void (*)(Nan::FunctionCallbackInfo<v8::Value> const&), Nan::imp::FunctionWrapper*> > >::__insert_node_at(std::__1::__tree_node_base<void*>*, std::__1::__tree_node_base<void*>*&, std::__1::__tree_node_base<void*>*) + 25 at __tree:1715
   1712     __new_node->__right_  = nullptr;
   1713     __new_node->__parent_ = __parent;
   1714     __child = __new_node;
-> 1715     if (__begin_node()->__left_ != nullptr)
   1716         __begin_node() = static_cast<__node_pointer>(__begin_node()->__left_);
   1717     __tree_balance_after_insert(__end_node()->__left_, __child);
   1718     ++size();

@lovell
Copy link
Owner
lovell commented Aug 26, 2015

Thank you, the backtrace you've provided is very useful. EXC_BAD_ACCESS (code=1, address=0x0) suggests we're looking at a null pointer problem.

The static std::map created inside Nan::GetWrapper https://github.com/nodejs/nan/blob/master/nan_callbacks.h#L110 fails at https://github.com/llvm-mirror/libcxx/blob/master/include/__tree#L1704 when an insert takes place.

Function statics should be thread-safe by default however http://stackoverflow.com/questions/17623815/why-does-compile-order-sometimes-cause-a-segmentation-fault-when-using-stdmap has a suggestion to use an Initializer Function Trick.

Give me a day or two to see if I can reproduce this problem consistently using clang/llvm. If so, this might require a change to the nan module.

@lovell
Copy link
Owner
lovell commented Aug 27, 2015

I can recreate this problem consistently using clang 6.0 (llvm 3.5) and io.js v3.2.0 with pretty much any two nan-based native modules that invoke a call to Nan::GetWrapper at require-time.

I think we've hit the same problem described in
http://stackoverflow.com/questions/19212474/clang-links-to-different-locations-when-referring-a-templated-static-variable-fr

@kkoopa are you able to provide any suggestions or help?

@kkoopa
Copy link
kkoopa commented Aug 27, 2015

Remove https://github.com/lovell/sharp/blob/master/binding.gyp#L66

On Thursday 27 August 2015 05:40:56 Lovell Fuller wrote:

I can recreate this problem consistently using clang 6.0 (llvm 3.5) and
io.js v3.2.0 with pretty much any two nan-based native modules that invoke
a call to Nan::GetWrapper at require-time.

I think we've hit the same problem described in
http://stackoverflow.com/questions/19212474/clang-links-to-different-locatio
ns-when-referring-a-templated-static-variable-fr

@kkoopa are you able to provide any suggestions or help?

Reply to this email directly or view it on GitHub:
#259 (comment)

@lovell
Copy link
Owner
lovell commented Aug 27, 2015

Thanks for the swift reply @kkoopa and great spot. The use of libc++ is to support the tuple type but given its current (lack of) use I should be able to replace it with the more portable pair type.

@lovell lovell added bug and removed triage labels Aug 27, 2015
@lovell
Copy link
Owner
lovell commented Aug 27, 2015

See also the related fsevents/fsevents#82 and possible fix nodejs/nan#431.

lovell added a commit that referenced this issue Aug 28, 2015
@lovell
Upgrade nan to fix clang linking problem #259
be00d72
@lovell
Copy link
Owner
lovell commented Aug 28, 2015

@aeosynth This should be fixed on the master branch - are you able to re-test?

@lovell lovell changed the title error when using with websockets Clang/llvm segfaults when using multiple C++ addons (was: error when using with websockets) Aug 28, 2015
@aeosynth
Copy link
Author

works for me, thanks!

@lovell lovell added this to the v0.11.2 milestone Aug 28, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
v0.11.2
Development

No branches or pull requests
3 participants
@aeosynth @lovell @kkoopa
0