ffi-napi 2.5.0 crashes on Node 14 on macOS 10.15.4

[nsabovic]

In an empty directory:

projects/test/testffi ❯ npm i ffi-napi

...

projects/test/testffi took 11s ❯ node
Welcome to Node.js v14.0.0.
Type ".help" for more information.
> os.version()
'Darwin Kernel Version 19.4.0: Wed Mar  4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64'

> require('ffi-napi')


#
# Fatal error in , line 0
# Check failed: result.second.
#
#
#
#FailureMessage Object: 0x7ffeefbf3330
 1: 0x1000d5142 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/usr/local/bin/node]
 2: 0x100a18c31 V8_Fatal(char const*, ...) [/usr/local/bin/node]
 3: 0x100378436 v8::internal::GlobalBackingStoreRegistry::Register(std::__1::shared_ptr<v8::internal::BackingStore>) [/usr/local/bin/node]
 4: 0x10018d9e7 v8::ArrayBuffer::GetBackingStore() [/usr/local/bin/node]
 5: 0x100063174 node::Buffer::New(node::Environment*, char*, unsigned long, void (*)(char*, void*), void*) [/usr/local/bin/node]
 6: 0x100062f0b node::Buffer::New(v8::Isolate*, char*, unsigned long, void (*)(char*, void*), void*) [/usr/local/bin/node]
 7: 0x10005ea05 napi_create_external_buffer [/usr/local/bin/node]
 8: 0x10418c99e Napi::Buffer<char> Napi::Buffer<char>::New<Napi::Value FFI::WrapPointer<_ffi_type>(Napi::Env, _ffi_type*, unsigned long)::'lambda'(Napi::Env, char*)>(napi_env__*, char*, unsigned long, _ffi_type) [/Users/nsabovic/projects/test/testffi/node_modules/ffi-napi/build/Release/ffi_bindings.node]
 9: 0x10418742b FFI::FFI::InitializeBindings(Napi::Env, Napi::Object) [/Users/nsabovic/projects/test/testffi/node_modules/ffi-napi/build/Release/ffi_bindings.node]
10: 0x10418b2a3 __napi_Init(napi_env__*, napi_value__*) [/Users/nsabovic/projects/test/testffi/node_modules/ffi-napi/build/Release/ffi_bindings.node]
11: 0x10005e048 napi_module_register_by_symbol(v8::Local<v8::Object>, v8::Local<v8::Value>, v8::Local<v8::Context>, napi_value__* (*)(napi_env__*, napi_value__*)) [/usr/local/bin/node]
12: 0x100061e83 std::__1::__function::__func<node::binding::DLOpen(v8::FunctionCallbackInfo<v8::Value> const&)::$_0, std::__1::allocator<node::binding::DLOpen(v8::FunctionCallbackInfo<v8::Value> const&)::$_0>, bool (node::binding::DLib*)>::operator()(node::binding::DLib*&&) [/usr/local/bin/node]
13: 0x100061034 node::binding::DLOpen(v8::FunctionCallbackInfo<v8::Value> const&) [/usr/local/bin/node]
14: 0x1001cd7ea v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/usr/local/bin/node]
15: 0x1001cce74 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) [/usr/local/bin/node]
16: 0x1001cc698 v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/usr/local/bin/node]
17: 0x10074fe79 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/usr/local/bin/node]
zsh: illegal hardware instruction  node

[vweevers]

Could be due to the prebuilt binary being built on a newer osx/xcode (cc @pimterry).

Could you try npm i ffi-napi --build-from-source?

[nsabovic]

Exactly the same result. Started with an empty directory, and built it from source. FYI, I have Xcode 11.4.1 installed.

[nsabovic]

I have tried it with node 14.0.0 (from Homebrew), and it doesn't work. node 13.13.0 worked. Also tried nvm, same story, 13.13.0 works but 14.0.0 does not.

[nsabovic]

If I were a betting man, I'd wager this had something to do with it:

nodejs/node#30782

In the thread, they also mention the same crash in deps/v8/src/objects/backing-store.cc.

[addaleax]

Yes – this is a known bug, and not easily addressable without major changes. #68 would take care of this, but it’ll definitely take so more time to work out everything there.

[addaleax]

@hjlld @felipebalbi I’ve hidden your comments. I appreciate the interest, but as I said, this is a known bug, and it takes some work to figure out how to work around the problems that the V8 updates pose to us (and making sure that those are correct). You can try #68, and if you want, I can make a pre-release using that branch, but be aware that that’s definitely still broken.

[splitice]

This also occurs on Armv7 (Raspberry PI equivilent) Linux with Nodejs 14+

#0  0x009b426c in v8::base::OS::Abort() ()
#1  0x01797b78 in V8_Fatal(char const*, ...) ()
#2  0x00e26f1c in v8::internal::GlobalBackingStoreRegistry::Register(std::shared_ptr<v8::internal::BackingStore>) ()
#3  0x00b7e1ac in v8::ArrayBuffer::GetBackingStore() ()
#4  0x00a14ff6 in node::Buffer::New(node::Environment*, char*, unsigned int, void (*)(char*, void*), void*) ()
#5  0x00a15368 in node::Buffer::New(v8::Isolate*, char*, unsigned int, void (*)(char*, void*), void*) ()
#6  0x00a0dcfc in napi_create_external_buffer ()
#7  0xb6449522 in Napi::Buffer<char> Napi::Buffer<char>::New<FFI::WrapPointer<_ffi_type>(Napi::Env, _ffi_type*, unsigned int)::{lambda(Napi::Env, char*)#1}>(napi_env__*, char*, unsigned int, FFI::WrapPointer<_ffi_type>(Napi::Env, _ffi_type*, unsigned int)::{lambda(Napi::Env, char*)#1}) [clone .constprop.70] ()
   from /usr/lib/node/nedb/node_modules/ffi-napi/build/Release/ffi_bindings.node
#8  0xb644c00c in FFI::FFI::InitializeBindings(Napi::Env, Napi::Object) () from /usr/lib/node/nedb/node_modules/ffi-napi/build/Release/ffi_bindings.node
#9  0xb644cec0 in Init(Napi::Env, Napi::Object) () from /usr/lib/node/nedb/node_modules/ffi-napi/build/Release/ffi_bindings.node
#10 0xb6449b6e in __napi_Init(napi_env__*, napi_value__*) () from /usr/lib/node/nedb/node_modules/ffi-napi/build/Release/ffi_bindings.node
#11 0x00a0d422 in napi_module_register_by_symbol(v8::Local<v8::Object>, v8::Local<v8::Value>, v8::Local<v8::Context>, napi_value__* (*)(napi_env__*, napi_value__*)) ()
#12 0x00a0fbfa in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Backtrace is slightly different however. Very similar though.

[addaleax]

This should be fixed in ffi-napi@3.x

[Yongle-Fu]

this bug still exists on ffi-napi 4.0.1

[rosek86]

Hello,

I have the same problem ffi-napi 4.0.2, tested on Node 14 and 15. This happens when a callback is executed:

const stdoutLogCallback = ffi.Callback('void', [ 'string' ], (msg) => {
  console.log('log:', msg);
});

Update:
The problem disappeared when I changed from ref-struct-napi / ref-array-napi to ref-struct-di / ref-array-di.