Skip to content

ffi-napi 2.5.0 crashes on Node 14 on macOS 10.15.4 #71

Closed

Description

@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

Activity

  1. vweevers commented on Apr 26, 2020

    @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?

  2. nsabovic commented on Apr 26, 2020

    @nsabovic
    Author

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

  3. nsabovic commented on Apr 26, 2020

    @nsabovic
    Author

    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.

  4. nsabovic commented on Apr 26, 2020

    @nsabovic
    Author

    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.

  5. addaleax commented on Apr 26, 2020

    @addaleax
    Contributor

    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.

  6. hjlld commented on Apr 28, 2020

    @hjlld
  7. felipebalbi commented on May 4, 2020

    @felipebalbi
  8. felipebalbi commented on May 4, 2020

    @felipebalbi
  9. addaleax commented on May 4, 2020

    @addaleax
    Contributor

    @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.

  10. splitice commented on May 6, 2020

    @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.

  11. addaleax commented on Jun 29, 2020

    @addaleax
    Contributor

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

  12. Yongle-Fu commented on Feb 26, 2021

    @Yongle-Fu

    this bug still exists on ffi-napi 4.0.1

  13. rosek86 commented on Mar 13, 2021

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions