FATAL ERROR: Error::ThrowAsJavaScriptException napi_throw

[watson]

I'm in the process of upgrading a large Node.js project from Node.js v16.17.1 to v18.12.0 and as part of that I'm upgrading our dependency on lmdb-store version 1.6.11 to lmdb version 2.6.8.

I've noticed (on my M1 MacBook) that I often get the following error from the C++ side of lmdb. I've so far not been able to track down under what conditions this happens. But any help/suggestions would be highly appreciated and possibly a bug-fix as this seems to be something that's not correctly handled internally by the library.

Let me know if there's anything I can do to extract more information that can be used to debug this issue.

FATAL ERROR: Error::ThrowAsJavaScriptException napi_throw
 1: 0x102dda200 node::Abort() [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
 2: 0x102dda2f8 node::OOMErrorHandler(char const*, bool) [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
 3: 0x102dda218 node::OnFatalError(char const*, char const*) [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
 4: 0x102daad58 napi_open_callback_scope [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
 5: 0x107e2a810 Napi::Error::Error(napi_env__*, napi_value__*) [/Users/watson/code/elastic/kibana/node_modules/@lmdb/lmdb-darwin-arm64/node.abi108.node]
 6: 0x107e2a7f8 Napi::Error::Fatal(char const*, char const*) [/Users/watson/code/elastic/kibana/node_modules/@lmdb/lmdb-darwin-arm64/node.abi108.node]
 7: 0x107e2b3d0 Napi::FunctionReference::Call(napi_value__*, std::initializer_list<napi_value__*> const&) const [/Users/watson/code/elastic/kibana/node_modules/@lmdb/lmdb-darwin-arm64/node.abi108.node]
 8: 0x107e2a40c Napi::AsyncWorker::OnError(Napi::Error const&) [/Users/watson/code/elastic/kibana/node_modules/@lmdb/lmdb-darwin-arm64/node.abi108.node]
 9: 0x107e2af0c napi_value__* Napi::details::WrapCallback<Napi::AsyncWorker::OnWorkComplete(Napi::Env, napi_status)::'lambda'()>(Napi::AsyncWorker::OnWorkComplete(Napi::Env, napi_status)::'lambda'()) [/Users/watson/code/elastic/kibana/node_modules/@lmdb/lmdb-darwin-arm64/node.abi108.node]
10: 0x107e2ae6c Napi::AsyncWorker::OnWorkComplete(Napi::Env, napi_status) [/Users/watson/code/elastic/kibana/node_modules/@lmdb/lmdb-darwin-arm64/node.abi108.node]
11: 0x102dacc70 (anonymous namespace)::uvimpl::Work::AfterThreadPoolWork(int) [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
12: 0x1036e8cbc uv__work_done [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
13: 0x1036ec458 uv__async_io [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
14: 0x1036fe1a4 uv__io_poll [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
15: 0x1036ec8e8 uv_run [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
16: 0x102d81734 node::Environment::CleanupHandles() [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
17: 0x102d81d7c node::Environment::RunCleanup() [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
18: 0x102d28204 node::FreeEnvironment(node::Environment*) [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
19: 0x102e6feb4 node::worker::Worker::Run() [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
20: 0x102e72fe4 node::worker::Worker::StartThread(v8::FunctionCallbackInfo<v8::Value> const&)::$_3::__invoke(void*) [/Users/watson/.nvm/versions/node/v18.12.0/bin/node]
21: 0x1a703c26c _pthread_start [/usr/lib/system/libsystem_pthread.dylib]
22: 0x1a703708c thread_start [/usr/lib/system/libsystem_pthread.dylib]

[kriszyp]

@watson Glad to hear kibana is upgrading lmdb-js, hopefully I can help with this. I am not exactly sure what is causing this particular error, but I am able to reproduce something similar by exit'ing worker threads while there are pending async operations, which is due to how node-addon-api interacts with node when it is in its weird thread-termination state. I made a few fixes to try to handle this situation. These are published in v2.6.9, if you want to give that a try and see if it addresses this.

[watson]

Thanks for the making the new release.

I think that it has solved the above issue. At least, I've not been able to recreate it after upgrading. The problem is that I yet haven't been able to isolate the issue and it seems to be a race-condition, so it doesn't always happen. But before your upgrade I got the above error about half the time I ran the code. So far I've run the code over 10 times without getting this error. I am however getting another error, but this time in Node.js land, which is probably the error that's now surfaced from the C++ side. So I'll close this issue for now as it seems to be fixed.

[kriszyp]

Yeah, the stack trace was going through an error handler, so I had wondered if there some other error that triggered this. But certainly don't want to crash in response to an error, so glad it is working better so far.