N-API module causes segfault on node 12.13.1, runs fine on 12.13.0

[s1hofmann]

• Node.js Version: 12.13.0 / 12.13.1
• OS: macOS
• Scope (install, code, runtime, meta, other?): Runtime
• Module (and version) (if relevant): https://www.npmjs.com/package/@nut-tree/libnut

I'm experiencing a macOS specific problem in my N-API addon libnut, no problems on Linux and Windows.
Up until node v12.13.0 everything is working fine, but with any node version >= v12.13.1, running e.g. the example snippet below causes a segfault and exits (original issue).

Any help or hints would be appreciated!

index.js

const libnut = require("@nut-tree/libnut");
libnut.keyTap("enter");

No error: nvm use 12.13.0 && node index.js
Segfault: nvm use 12.13.1 && node index.js

Stacktrace:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x141)
  * frame #0: 0x0000000102877bc5 dyld`dyld::fastBindLazySymbol(ImageLoader**, unsigned long) + 80
    frame #1: 0x00007fff65012246 libdyld.dylib`dyld_stub_binder + 282
    frame #2: 0x0000000102d56730 libnut.node
    frame #3: 0x0000000102d51cc6 libnut.node`tapKeyCode(code=36, flags=MOD_NONE) at keypress.c:160:2
    frame #4: 0x0000000102d46241 libnut.node`_keyTap(info=0x00007ffeefbfe3b8) at libnut.cc:506:3
    frame #5: 0x0000000102d5008b libnut.node`Napi::details::CallbackData<Napi::Number (*)(Napi::CallbackInfo const&), Napi::Number>::Wrapper(this=0x00007ffeefbfe498)::'lambda'()::operator()() const at napi-inl.h:82:14
    frame #6: 0x0000000102d4ff39 libnut.node`napi_value__* Napi::details::WrapCallback<Napi::details::CallbackData<Napi::Number (*)(Napi::CallbackInfo const&), Napi::Number>::Wrapper(napi_env__*, napi_callback_info__*)::'lambda'()>(callback=(anonymous class) @ 0x00007ffeefbfe498)(Napi::CallbackInfo const&), Napi::Number>::Wrapper(napi_env__*, napi_callback_info__*)::'lambda'()) at napi-inl.h:61:12
    frame #7: 0x0000000102d4fd8d libnut.node`Napi::details::CallbackData<Napi::Number (*)(Napi::CallbackInfo const&), Napi::Number>::Wrapper(env=0x0000000102c14e00, info=0x00007ffeefbfe4f8) at napi-inl.h:77:12
    frame #8: 0x000000010004310f node`v8impl::(anonymous namespace)::FunctionCallbackWrapper::Invoke(v8::FunctionCallbackInfo<v8::Value> const&) + 127
    frame #9: 0x00000001001e1650 node`v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) + 544
    frame #10: 0x00000001001e0c2f node`v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) + 543
    frame #11: 0x00000001001e0330 node`v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) + 272
    frame #12: 0x0000000100930d99 node`Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit + 57
    frame #13: 0x00000001008b12e4 node`Builtins_InterpreterEntryTrampoline + 676
    frame #14: 0x00000001008b12e4 node`Builtins_InterpreterEntryTrampoline + 676
    frame #15: 0x00000001008b12e4 node`Builtins_InterpreterEntryTrampoline + 676
    frame #16: 0x00000001008b12e4 node`Builtins_InterpreterEntryTrampoline + 676
    frame #17: 0x00000001008b12e4 node`Builtins_InterpreterEntryTrampoline + 676
    frame #18: 0x00000001008b12e4 node`Builtins_InterpreterEntryTrampoline + 676
    frame #19: 0x00000001008b12e4 node`Builtins_InterpreterEntryTrampoline + 676
    frame #20: 0x00000001008ae8dd node`Builtins_JSEntryTrampoline + 93
    frame #21: 0x00000001008ae6b8 node`Builtins_JSEntry + 120
    frame #22: 0x0000000100299203 node`v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) + 771
    frame #23: 0x0000000100298eea 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>*) + 202
    frame #24: 0x00000001001942f4 node`v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) + 628
    frame #25: 0x0000000100059138 node`node::ExecuteBootstrapper(node::Environment*, char const*, std::__1::vector<v8::Local<v8::String>, std::__1::allocator<v8::Local<v8::String> > >*, std::__1::vector<v8::Local<v8::Value>, std::__1::allocator<v8::Local<v8::Value> > >*) + 112
    frame #26: 0x0000000100059e81 node`node::StartExecution(node::Environment*, char const*) + 470
    frame #27: 0x000000010005a048 node`node::StartMainThreadExecution(node::Environment*) + 217
    frame #28: 0x00000001000b4a88 node`node::NodeMainInstance::Run() + 278
    frame #29: 0x000000010005b817 node`node::Start(int, char**) + 294
    frame #30: 0x00007fff650137fd libdyld.dylib`start + 1

[addaleax]

@nodejs/platform-macos

[bnoordhuis]

Since the crash happens in dyld, the dynamic linker, and the address is invalid, my hunch is that this is some kind of memory corruption that may have been dormant until now (i.e., it worked by accident until it didn't.) Is the backtrace always exactly the same?

I suppose it's possible that nodejs/node@2764567f90 is responsible because that contains a change where libuv now loads CoreFoundation.framework eagerly (libuv/libuv@038eacfbf4, already reverted in libuv's v1.x branch because of regressions), which your code also depends on.

You could try reverting that commit and see if it makes a difference.

[s1hofmann]

Hi @bnoordhuis, thanks for reaching out!

Is the backtrace always exactly the same?

Yes, it is the same for 12.13.1, 12.14.0 and 12.14.1

You could try reverting that commit and see if it makes a difference.

Since I have not yet built node myself I could need a little help on this.
Any guides I could follow?

[bnoordhuis]

There's a BUILDING.md in the source tarball that lists the prerequisites and steps but normally it's just a ./configure && make -j8. You don't have to install the binary, you can just run it from the out/Release directory.

edit: but if you want to revert that commit, it's probably easier to git clone the repo and check out the right tag.

[s1hofmann]

@bnoordhuis I spent some time investigating on this issue yesterday evening. The issue persists up until node v13.7.0. I traced the changelog and identified the update to libuv v1.34.1 to solve the issue.

Rebuilding node v12.16.0 (lts/erbium) after an update from libuv v1.34.0 to v1.34.1 solves the issue.

You might take a look at this as well?

[PoojaDurgad]

@s1hofmann - looks like this issue can be closed now .please let me know if that is not the case

[s1hofmann]

@PoojaDurgad Yes, issue has been resolved. Closing.