Access violation in TypedArrayOf

[aminya]

When I build zmq.js with address sanitizer, and I attach my debugger to the node process that runs the tests (./node_modules/.bin/mocha), I get this error from the following location:

https://github.com/nodejs/node-addon-api/blob/77350eee98957f471a355a4cf12f6ee05262fa5b/napi-inl.h#L1892-1904

template <typename T>
inline TypedArrayOf<T>::TypedArrayOf(napi_env env, napi_value value)
  : TypedArray(env, value), _data(nullptr) {
  napi_status status = napi_ok;
  if (value != nullptr) {
    status = napi_get_typedarray_info(
      _env, _value, &_type, &_length, reinterpret_cast<void**>(&_data), nullptr, nullptr); // happens here 
  } else {
    _type = TypedArrayTypeForPrimitiveType<T>();
    _length = 0;
  }
  NAPI_THROW_IF_FAILED_VOID(_env, status);

Exception thrown at 0x0000000000000000 in node.exe: 0xC0000005: Access violation executing location 0x0000000000000000.

The undefined behaviour of reintrepret_cast can be the reason why this happens.
https://www.youtube.com/watch?v=L06nbZXD2D0

[legendecas]

@aminya Can you provide more details about the error you got? It will help people to understand the problems here. Thanks a lot.

[aminya]

I also get this error at the same time at the end of the test, which is from this line

Right after this test:
https://github.com/aminya/zeromq.js/blob/8cdcef739abd56a97c2af5e91c56400b9eb94f83/test/unit/socket-send-receive-test.ts#L123

.\node_modules\.bin\mocha .\test\unit\socket-send-receive-test.ts

The values right before the error at this line from inside the lambda

And when the exception is thrown from napi:

#
# Fatal error in , line 0
# Check failed: result.second.
#
#
#
#FailureMessage Object: 0000003DA15AD490
 1: 00007FF7ECBAB8BF v8::internal::Isolate::ArchiveSpacePerThread+4719
 2: 00007FF7ECACB63F v8::CFunction::ReturnInfo+2271
 3: 00007FF7ED761EE2 V8_Fatal+162
 4: 00007FF7ED1D30CD v8::internal::BackingStore::Reallocate+653
 5: 00007FF7ED42C7E9 v8::ArrayBuffer::GetBackingStore+137
 6: 00007FF7ECB81069 napi_get_typedarray_info+393
 7: 00007FFE5019196E Napi::TypedArrayOf<unsigned char>::TypedArrayOf<unsigned char>+222 [C:\Users\aminy\Documents\GitHub\zeromq.js\node_modules\.pnpm\node-addon-api@3.1.0\node_modules\node-addon-api\napi-inl.h]:L1898
 8: 00007FFE501917A1 Napi::Buffer<unsigned char>::Buffer<unsigned char>+65 [C:\Users\aminy\Documents\GitHub\zeromq.js\node_modules\.pnpm\node-addon-api@3.1.0\node_modules\node-addon-api\napi-inl.h]:L2242
 9: 00007FFE501915A1 Napi::Buffer<unsigned char>::New<<lambda_38a9f3a7be0ecbda5d7a977118e1cc87>,zmq::IncomingMsg::Reference>+385 [C:\Users\aminy\Documents\GitHub\zeromq.js\node_modules\.pnpm\node-addon-api@3.1.0\node_modules\node-addon-api\napi-inl.h]:L2221
10: 00007FFE5026873C zmq::IncomingMsg::IntoBuffer+460 [C:\Users\aminy\Documents\GitHub\zeromq.js\src\incoming_msg.cc]:L44
11: 00007FFE501B241F zmq::Socket::Receive+527 [C:\Users\aminy\Documents\GitHub\zeromq.js\src\socket.cc]:L312
12: 00007FFE501B43D8 zmq::Socket::Receive+776 [C:\Users\aminy\Documents\GitHub\zeromq.js\src\socket.cc]:L603
13: 00007FFE501BC935 <lambda_54eea5ffa672b7afc2354026b7effdaa>::operator()+309 [C:\Users\aminy\Documents\GitHub\zeromq.js\node_modules\.pnpm\node-addon-api@3.1.0\node_modules\node-addon-api\napi-inl.h]:L157
14: 00007FFE501C0C5D Napi::details::WrapCallback<<lambda_54eea5ffa672b7afc2354026b7effdaa> >+45 [C:\Users\aminy\Documents\GitHub\zeromq.js\node_modules\.pnpm\node-addon-api@3.1.0\node_modules\node-addon-api\napi-inl.h]:L68
15: 00007FFE50271E44 Napi::details::TemplatedInstanceCallback<zmq::Socket,{zmq::Socket::Receive,0,0,0}>+84 [C:\Users\aminy\Documents\GitHub\zeromq.js\node_modules\.pnpm\node-addon-api@3.1.0\node_modules\node-addon-api\napi-inl.h]:L154
16: 00007FF7ECB7B9C6 node::Stop+36198
17: 00007FF7ED3F23CF v8::internal::Builtins::builtin_handle+316367
18: 00007FF7ED3F1954 v8::internal::Builtins::builtin_handle+313684
19: 00007FF7ED3F1C55 v8::internal::Builtins::builtin_handle+314453
20: 00007FF7ED3F1A93 v8::internal::Builtins::builtin_handle+314003
21: 00007FF7ED4CD7FD v8::internal::SetupIsolateDelegate::SetupHeap+456973
22: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
23: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
24: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
25: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
26: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
27: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
28: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
29: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
30: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
31: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
32: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
33: 00007FF7ED466082 v8::internal::SetupIsolateDelegate::SetupHeap+33170
34: 00007FF7ED519DAE v8::internal::SetupIsolateDelegate::SetupHeap+769726
35: 00007FF7ED48531F v8::internal::SetupIsolateDelegate::SetupHeap+160815
36: 00007FF7ED463C2C v8::internal::SetupIsolateDelegate::SetupHeap+23868
37: 00007FF7ED32D36C v8::internal::Execution::CallWasm+1836
38: 00007FF7ED32D47B v8::internal::Execution::CallWasm+2107
39: 00007FF7ED32DEFA v8::internal::Execution::TryCall+378
40: 00007FF7ED308C65 v8::internal::MicrotaskQueue::RunMicrotasks+501
41: 00007FF7ED3089C0 v8::internal::MicrotaskQueue::PerformCheckpoint+32
42: 00007FF7ECBD2D34 node::CallbackScope::~CallbackScope+692
43: 00007FF7ECBD2AB4 node::CallbackScope::~CallbackScope+52
44: 00007FF7ECB6C108 napi_close_callback_scope+88
45: 00007FFE501A5375 Napi::CallbackScope::~CallbackScope+69 [C:\Users\aminy\Documents\GitHub\zeromq.js\node_modules\.pnpm\node-addon-api@3.1.0\node_modules\node-addon-api\napi-inl.h]:L4131
46: 00007FFE501A6A4F zmq::AsyncScope::~AsyncScope+47
47: 00007FFE501B2D21 <lambda_57c5e8bd649d0668b016571c3f0c3c52>::operator()+705 [C:\Users\aminy\Documents\GitHub\zeromq.js\src\socket.cc]:L380
48: 00007FFE501BADE6 <lambda_bc01645912f1e98f4a7ae4973055204b>::operator()+70 [C:\Users\aminy\Documents\GitHub\zeromq.js\src\util\uvwork.h]:L32
49: 00007FFE501BAE53 <lambda_bc01645912f1e98f4a7ae4973055204b>::<lambda_invoker_cdecl>+51 [C:\Users\aminy\Documents\GitHub\zeromq.js\src\util\uvwork.h]:L33
50: 00007FF7ECC06FD0 uv_timer_stop+560
51: 00007FF7ECC070A7 uv_timer_stop+775
52: 00007FF7ECC038AB uv_async_send+331
53: 00007FF7ECC0303C uv_loop_init+1292
54: 00007FF7ECC031DA uv_run+202
55: 00007FF7ECBD24E4 node::SpinEventLoop+308
56: 00007FF7ECAF8287 v8::internal::compiler::JSHeapBroker::root_index_map+53111
57: 00007FF7ECB7224B node::Start+283
58: 00007FF7EC99822C RC4_options+346412
59: 00007FF7ED9E016C v8::internal::compiler::RepresentationChanger::Uint32OverflowOperatorFor+152060
60: 00007FFEFC0B7034 BaseThreadInitThunk+20
61: 00007FFEFD622651 RtlUserThreadStart+33

[aminya]

@legendecas Any clue if this is an N-api issue or the package issue?

[legendecas]

In a quick look, this seems similar to nodejs/node#32463, in which v8 asserts that no backing store should be created on the same buffer.

However I found that the 4th frame v8::internal::BackingStore::Reallocate is not what I expect as v8::internal::GlobalBackingStoreRegistry::Register, can you share your Node.js version you are testing against so that I can take a deep look into it?

[aminya]

can you share your Node.js version you are testing against so that I can take a deep look into it?

Thanks. I am on the latest version (15.x).

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

[aminya]

AFAIK, that's not a good way to manage issues

[KevinEady]

Hi @aminya ,

I have added this issue to our "stale issues to discuss" list for the next Node-API meeting. We will hopefully have an update then.

NB: The stale issues bot keeps our issues down by automatically closing issues, eg. where we have requested information from OP but have not received anything yet. In instances like this however, it helps remind us of issues that we have accidentally lost track of, as we receive an email notification when the bot labels things as stale.

[mhdawson]

@aminya we discussed this in the node-api team meeting today and one thing we saw was that there was a change in zeromq - zeromq/zeromq.js#444. Can you confirm if you still see the issue after that update?

[aminya]

Yes, the issue still happened after I merged that. I will try to reproduce it again with the new updates in node-addon-api.

[aminya]

The undefined behaviour of reintrepret_cast can be the reason why this happens.
https://www.youtube.com/watch?v=L06nbZXD2D0

[mhdawson]

@aminya not sure from your comment if you reproduced it again with the new node-addon-api updates ?

[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]

Added to the list we discuss in the weekly meetings.

[mhdawson]

@aminya can you confirm this is still an issue that you see. I don't see any confirmation since my comment on Aug 3rd.

Do you have a specific reason why you believe the reinterpret cast is a problem? If you show a change to the code that resolves the issue by not using reinterpret cast that might be a good way to illustrate why that is the problem.

Is there a smaller easily run recreate that shows the failure?

[mhdawson]

We discussed in the Node-API team meeting today. @aminya we will need your help to continue to investigate and since there have not been responses for a number of months we are going to close for now. If it is still and issue and you you are available again to help investigate again please re-open.