Shared memory buffer causes crash

[RossComputerGuy]

Header: https://github.com/emberliteOS/core/blob/v1.1.x/include/shell/window.h
Code: https://github.com/emberliteOS/core/blob/v1.1.x/src/shell/window.cc

Related function in my code: Window::GetBuffer

> win.buffer

#
# Fatal error in , line 0
# Check failed: result.second.
#
#
#
#FailureMessage Object: 0x7fff5e893610
 1: 0x563653069463  [node]
 2: 0x563653aadf18 V8_Fatal(char const*, ...) [node]
 3: 0x5636534428b4 v8::internal::GlobalBackingStoreRegistry::Register(std::shared_ptr<v8::internal::BackingStore>) [node]
 4: 0x5636531b0122 v8::ArrayBuffer::GetBackingStore() [node]
 5: 0x563652faa3f6 napi_get_typedarray_info [node]
 6: 0x7fb035a0f82e Window::GetBuffer(Napi::CallbackInfo const&) [/home/ross/emberliteOS/core/build/Release/shell.node]
 7: 0x7fb035a1166a napi_value__* Napi::ObjectWrap<Window>::WrappedMethod<&Window::GetBuffer>(napi_env__*, napi_callback_info__*) [/home/ross/emberliteOS/core/build/Release/shell.node]
 8: 0x563652fa0eb5  [node]
 9: 0x56365391708d  [node]
zsh: illegal hardware instruction (core dumped)  node

Repl shows the buffer for a second then it crashes. I have no idea why this crash is happening and how to fix it.

[RossComputerGuy]

I've been working on this all day and any sort of buffer I use causes a crash.

[Superlokkus]

Both your links are broken i.e. resulting in 404.

[RossComputerGuy]

That's because I changed my code a bunch since I couldn't get help.

• https://github.com/emberliteOS/core/blob/c8e8b2b0115b49a3da660207ccff4320eb6e5173/include/shell/window.h
• https://github.com/emberliteOS/core/blob/c8e8b2b0115b49a3da660207ccff4320eb6e5173/src/shell/window.cc

[KevinEady]

Hi @RossComputerGuy ,

I was not able to reproduce your issue in your code. I stubbed out the definitions of mfb_* and WF_*. Are these functions doing anything with multiple threads, or...?

[RossComputerGuy]

Those come from https://github.com/emoon/minifb

[melchor629]

I'm also facing this issue but only when I use node 14.x (on 10 and 12, everything is fine). This time for my project https://github.com/melchor629/node-flac-bindings. I always have the crash when I run the tests:

#
# Fatal error in , line 0
# Check failed: result.second.
#
#
#
#FailureMessage Object: 0x7ffeefbfdbb0
 1: 0x1001137c2 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/Users/melchor9000/.nvm/versions/node/v14.15.0/bin/node]
 2: 0x10100e4d2 V8_Fatal(char const*, ...) [/Users/melchor9000/.nvm/versions/node/v14.15.0/bin/node]
 3: 0x1004d4d44 v8::internal::GlobalBackingStoreRegistry::Register(std::__1::shared_ptr<v8::internal::BackingStore>) [/Users/melchor9000/.nvm/versions/node/v14.15.0/bin/node]
 4: 0x1001fa9b6 v8::ArrayBuffer::GetBackingStore() [/Users/melchor9000/.nvm/versions/node/v14.15.0/bin/node]
 5: 0x100069fce napi_get_typedarray_info [/Users/melchor9000/.nvm/versions/node/v14.15.0/bin/node]
 6: 0x1098333c2 Napi::TypedArrayOf<unsigned char>::TypedArrayOf(napi_env__*, napi_value__*) [/Volumes/OSX/Programacion/node/flac-bindings/build/Debug/flac-bindings.node]
 7: 0x109833307 Napi::Buffer<int>::Buffer(napi_env__*, napi_value__*, unsigned long, int*) [/Volumes/OSX/Programacion/node/flac-bindings/build/Debug/flac-bindings.node]
 8: 0x1098332c5 Napi::Buffer<int>::Buffer(napi_env__*, napi_value__*, unsigned long, int*) [/Volumes/OSX/Programacion/node/flac-bindings/build/Debug/flac-bindings.node]
 9: 0x109833276 Napi::Buffer<unsigned char>::New(napi_env__*, unsigned char*, unsigned long) [/Volumes/OSX/Programacion/node/flac-bindings/build/Debug/flac-bindings.node]
10: 0x1098051b7 Napi::Buffer<unsigned char> flac_bindings::pointer::wrap<unsigned char>(Napi::Env const&, unsigned char*, unsigned long) [/.../flac-bindings/build/Debug/flac-bindings.node]

The crash happens when I create a Buffer from a shared pointer (probably reused several times).

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[mhdawson]

This looks like it is related to: nodejs/node#32463 and this https://monorail-prod.appspot.com/p/v8/issues/detail?id=9908 which is quoted as indicating that it is intentional.

[oldmtn]

Is there any method to workaround this issue?

[RossComputerGuy]

There isn't any that I know of

[melchor629]

I found like a workaround, but just if you can control the scope of the buffers: when the buffer is no longer needed, napi_detach_arraybuffer (see also) on the ArrayBuffer (or any Buffer getting its ArrayBuffer with buffer.ArrayBuffer()) avoids the issue. But you need to constantly create buffers from the memory and detaching it after use. An example:

size_t sharedMemoryLength = /* ... */;
uint8_t* sharedMemory = /* ... */;
// wrap into node Buffer
auto jsBuffer = napi::Buffer::New(env, sharedMemory, sharedMemoryLength);
// send it to JS
someJsCallback({jsBuffer});
// detach after use
jsBuffer.ArrayBuffer().Detach();

For C++ wrapped objects that contains some pointers to shared memory, instead I cache the Buffer into an ObjectReference to avoid wrapping and detaching the memory constantly.

NOTE: Requires NAPI version 7 in order to use .Detach()

Hope it helps.