Skip to content
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.

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

node-gyp crashes on OS X 10.11, but only when run from emacs #934

Closed
tomjakubowski opened this issue May 19, 2016 · 2 comments
Closed

node-gyp crashes on OS X 10.11, but only when run from emacs #934

tomjakubowski opened this issue May 19, 2016 · 2 comments

Comments

@tomjakubowski
Copy link

Well this is a real head-scratcher…

I recently upgraded to node-gyp v3.3.1 and node v6.1.0. Since then, I can run node-gyp list or node-gyp build without issue from zsh in iTerm2, but if I run it from inside emacs (whether from eshell-mode, shell-mode, or simply compilation-mode) I see an abort:

% node-gyp list
node-gyp list
gyp info it worked if it ends with ok
gyp info using node-gyp@3.3.1
gyp info using node@6.1.0 | darwin | x64
zsh: abort      node-gyp list

The following commands all abort this way: build, clean, configure, rebuild, install, list, remove. node-gyp --version and node-gyp --help do not abort.

Here's a backtrace:

(lldb) bt
bt
* thread #1: tid = 0x411452, 0x00007fff980cbf06 libsystem_kernel.dylib`__pthread_kill + 10, name = 'node-gyp', queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff980cbf06 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff8b0ee4ec libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x00007fff9fb896e7 libsystem_c.dylib`abort + 129
    frame #3: 0x000000010071770d node`uv_thread_create + 237
    frame #4: 0x000000010070b1da node`init_once + 266
    frame #5: 0x00007fff8b0ebbf6 libsystem_pthread.dylib`__pthread_once_handler + 65
    frame #6: 0x00007fff9e47afc4 libsystem_platform.dylib`_os_once + 41
    frame #7: 0x00007fff8b0ebb95 libsystem_pthread.dylib`pthread_once + 57
    frame #8: 0x0000000100717904 node`uv_once + 9
    frame #9: 0x000000010070b0b4 node`uv__work_submit + 42
  * frame #10: 0x000000010071032e node`uv_fs_scandir + 239
    frame #11: 0x00000001005faf01 node`node::ReadDir(v8::FunctionCallbackInfo<v8::Value> const&) + 532
    frame #12: 0x00000001001742fb node`v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) + 371
    frame #13: 0x000000010019e5f2 node`v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>) + 992
    frame #14: 0x00000001001ac256 node`v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) + 105
    frame #15: 0x00002e8ce430961b
    frame #16: 0x00002e8ce44a599a
    frame #17: 0x00002e8ce430d157
    frame #18: 0x00002e8ce44a54ba
    frame #19: 0x00002e8ce430d157
    frame #20: 0x00002e8ce44a53b2
    frame #21: 0x00002e8ce44a515f
    frame #22: 0x00002e8ce44a41e0
    frame #23: 0x00002e8ce44a4069
    frame #24: 0x00002e8ce4443955
    frame #25: 0x00002e8ce4442884
    frame #26: 0x00002e8ce443b3ab
    frame #27: 0x00002e8ce4439db2
    frame #28: 0x00002e8ce44398dd
    frame #29: 0x00002e8ce4435522
    frame #30: 0x00002e8ce4434fea
    frame #31: 0x00002e8ce43408a2
    frame #32: 0x00002e8ce433e4f2
    frame #33: 0x00002e8ce4337f84
    frame #34: 0x00002e8ce4322922
    frame #35: 0x0000000100336bc0 node`v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, bool, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, v8::internal::Handle<v8::internal::Object>) + 406
    frame #36: 0x000000010033695b node`v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) + 459
    frame #37: 0x000000010015d669 node`v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) + 417
    frame #38: 0x00000001005df9b7 node`node::LoadEnvironment(node::Environment*) + 625
    frame #39: 0x00000001005e0f3e node`node::Start(int, char**) + 517
    frame #40: 0x0000000100001f34 node`start + 52
@tomjakubowski
Copy link
Author

And with verbose logging:

% node-gyp list --verbose
node-gyp list --verbose
gyp info it worked if it ends with ok
gyp verb cli [ '/usr/local/Cellar/node/6.1.0/bin/node',
gyp verb cli   '/Users/tjakubowski/.local/bin/node-gyp',
gyp verb cli   'list',
gyp verb cli   '--verbose' ]
gyp info using node-gyp@3.3.1
gyp info using node@6.1.0 | darwin | x64
gyp verb command list []
gyp verb list using node-gyp dir: /Users/tjakubowski/.node-gyp
zsh: abort      node-gyp list --verbose

@tomjakubowski
Copy link
Author

Aha, not just a node-gyp issue. node by itself crashes in a similar way. Filing over there!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant