Getting error 0xbe52c6 v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [node]

[brendon-flanagan]

Error is intermittent but frequent.

Sequence is where I'm opening a connection, opening a request queue, opening a reply queue, then closing all in sequence.

Run this about 2 to 3 times and about the 3rd or 4th time it crashes with the below, during either opening the request queue or reply queue..

Full error (but removed path info)

#
# Fatal error in , line 0
# Check failed: result.second.
#
#
#
#FailureMessage Object: 0x7ffec8005fb0
 1: 0xa70141  [node]
 2: 0x19cf094 V8_Fatal(char const*, ...) [node]
 3: 0xe594c9 v8::internal::GlobalBackingStoreRegistry::Register(std::shared_ptr<v8::internal::BackingStore>) [node]
 4: 0xba4a18 v8::ArrayBuffer::GetBackingStore() [node]
 5: 0x9c18f0 napi_get_typedarray_info [node]
 6: 0x7f80210e84e6  [/<removed>/node_modules/ref-napi/build/Release/binding.node]
 7: 0x7f80210ea27c  [/<removed>/node_modules/ref-napi/build/Release/binding.node]
 8: 0x7f80210f1138 Napi::details::CallbackData<void (*)(Napi::CallbackInfo const&), void>::Wrapper(napi_env__*, napi_callback_info__*) [/<removed>/node_modules/ref-napi/build/Release/binding.node]
 9: 0x9b8c8f  [node]
10: 0xbe369b  [node]
11: 0xbe4c46  [node]
12: 0xbe52c6 v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [node]
13: 0x13ff259  [node]
Aborted (core dumped)

node v14.15.1
npm v6.14.8
ibmmq v0.9.16
ref-napi v3.0.1

Above is in redhat 7

Have also tried in windows svr 2016

And simplified down to just opening a connection then a queue, closing the queue, closing the connection, repeat several times in a row and eventually.

#
# Fatal error in , line 0
# Check failed: result.second.
#
#
#
#FailureMessage Object: 0000005A03B2CFE0
 1: 00007FF6D019021F napi_wrap+109311
 2: 00007FF6D00C48DF std::basic_ostream<char,std::char_traits<char> >::operator<<+57151
 3: 00007FF6D0CFD442 V8_Fatal+162
 4: 00007FF6D07A12ED v8::internal::BackingStore::Reallocate+653
 5: 00007FF6D09E7129 v8::ArrayBuffer::GetBackingStore+137
 6: 00007FF6D0172119 napi_get_typedarray_info+393
 7: 00007FFB39B29B41
 8: 00007FFB39B2F28D
 9: 00007FFB39B27EC3
10: 00007FFB39B2EAE3
11: 00007FF6D016C9C6 node::Stop+35286
12: 00007FF6D09AD76F v8::internal::Builtins::builtin_handle+321471
13: 00007FF6D09ACD04 v8::internal::Builtins::builtin_handle+318804
14: 00007FF6D09ACFF7 v8::internal::Builtins::builtin_handle+319559
15: 00007FF6D09ACE43 v8::internal::Builtins::builtin_handle+319123
16: 00007FF6D0A88FDD v8::internal::SetupIsolateDelegate::SetupHeap+464173
17: 00007FF6D0A218E2 v8::internal::SetupIsolateDelegate::SetupHeap+40498
18: 000000E3E5F6A3B5
npm ERR! code ELIFECYCLE

[nidibm]

I am also hitting the same error ,
Saw this error after MQRC_NO_SUBS_MATCHED error hit .
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR #
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR # Fatal error in , line 0
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR # Check failed: result.second.
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR #
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR #
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR #
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR #FailureMessage Object: 0x7ffe4cd50650
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 1: 0xa71261 [node]
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 2: 0x19d3254 V8_Fatal(char const*, ...) [node]
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 3: 0xe5b549 v8::internal::GlobalBackingStoreRegistry::Register(std::shared_ptrv8::internal::BackingStore) [node]
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 4: 0xba6a98 v8::ArrayBuffer::GetBackingStore() [node]
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 5: 0x9dba9f node::Buffer::Data(v8::Localv8::Value) [node]
2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 6: 0xad211e

Due to which APP is getting crashed , @ibmmqmet Please look into this .

[ibmmqmet]

I've been trying to see if there's anything I can do here. But it does look like there are still issues with either the node engine itself, or with the ref-napi/ffi-napi dependencies. I do at least have a program that reproduces the problems in a node 14 (and 15) environment. One problem with the program is that it relies on having an MQ qmgr environment; not something I can expect people working on these underlying pieces to be familiar with.

There are already issues raised against these other components so I can link to them here:

node-ffi-napi/ref-napi#47
nodejs/node#32463

I'm investigating if there are any alternative approaches to avoid these issues but I'm not very hopeful. I don't know enough about the internals of the engine to try to solve it and offer a fix myself - but I may need to have a go at that. Though anyone else could try to debug it too. Maybe the linked issues can give a starting point.

[brendon-flanagan]

Thanks For now I’m now trying a different approach to instead use the java mq libraries instead via the node-java bridge (https://www.npmjs.com/package/java). Early days as only just started looking at, but I got as far as initial connectivity to a qmgr, just to see that node-java bridge was going to work. For MQ, you could try setting up a docker image that already has everything one needs in it out of the box ? Just a thought. B. From: Mark Taylor <[email protected]> Sent: Thursday, 21 January 2021 3:48 AM To: ibm-messaging/mq-mqi-nodejs <[email protected]> Cc: Flanagan, Brendon <[email protected]>; Author <[email protected]> Subject: Re: [ibm-messaging/mq-mqi-nodejs] Getting error 0xbe52c6 v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [node] (#108) I've been trying to see if there's anything I can do here. But it does look like there are still issues with either the node engine itself, or with the ref-napi/ffi-napi dependencies. I do at least have a program that reproduces the problems in a node 14 (and 15) environment. One problem with the program is that it relies on having an MQ qmgr environment; not something I can expect people working on these underlying pieces to be familiar with. There are already issues raised against these other components so I can link to them here: node-ffi-napi/ref-napi#47<node-ffi-napi/ref-napi#47> nodejs/node#32463<nodejs/node#32463> I'm investigating if there are any alternative approaches to avoid these issues but I'm not very hopeful. I don't know enough about the internals of the engine to try to solve it and offer a fix myself - but I may need to have a go at that. Though anyone else could try to debug it too. Maybe the linked issues can give a starting point. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#108 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ARV36Z3LFFXB2V6RQVI6HGLS23UIVANCNFSM4VE4NIUA>. "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication."

[ibmmqmet]

Of my various testcases that show failures in Node or the ref prereqs, none of them seem to fail right now with v12.20.1. Some of the failures happened with older levels of v12; some with v14. Unless/until there are fixes found, then that might need to be the recommended level.

[ibmmqmet]

node-ffi-napi/ref-napi#55 seems to resolve this - at least my testcase is on iteration 4000 right now instead of crashing when <50. So assuming that gets accepted, once it's available via npm I can update the prereq

[nidibm]

@ibmmqmet I see node-ffi-napi/ref-napi#55 PR has been merged and the fix is available in [email protected] , which will be picked by this module . But i see here https://github.com/node-ffi-napi/node-ffi-napi/blob/master/package.json#L33 that ffi-napi consumes ref-napi": "^2.0.1 , does this needs to be updated to consume the fix .

[ibmmqmet]

Branch ref-napi-fix in this repo pulls in the updated dependencies. That will give people a chance to try it.
You can use "ibmmq":"ibm-messaging/mq-mqi-nodejs#ref-napi-fix" in package.json dependencies section.

Assuming it works (and it does work in my test cases that previously failed), I would expect to release a new formal level via npm soon.

[hellerim]

In a program I'm writing I have a similar issue if not the same. Connecting and creating/opening up to three queues appears to be uncritical. My program gets its input from a tcp socket, passes it onto one of two permanent queues depending on whether it's a request or a datgram, and picks replies from a dynamic queue to send them back to the tcp client. However, every 20 minutes or so, the tcp connection needs to be reestablished which I tried to handle completely within the connection handler of the server. However, it was not able to handle more than three connections at once, nor did it survive a reconnect attempt from the tcp client. Each time, node crashed with more or less the same error report which clearly points to ffi-napi. Now, I'm forking a new process each time a new tcp connection is established, and it appears to work fine so far. This is feasible since there are not thousands of simultaneous connections to expect. However, even if I kept up this solution, I'd like to work with a "trustworthy" library (not intended to offend soeone ;)), so I'll try this patch and tell you if it works. Otherwise, @ibmmqmet, chapeau and thanks for the great work you did!

[hellerim]

I was trying to npm i the modified branch, "ibmmq":"ibm-messaging/mq-mqi-nodejs#ref-napi-fix", but host verification failed (using the standard github host fingerprint), Is there something I need to know?

[ibmmqmet]

A quick search via google suggests that either your version of npm needs to be updated, or you need to update ssh keys for github. See for example https://stackoverflow.com/questions/63806821/npm-install-error-host-key-verification-failed

[hellerim]

I'd done all this already, but the problem remains. Maybe I’ll have to further investigate. I’m really interested to know if my problems disappear with the new version. I'm just finishing a refactoring of my software so that it can be loaded as a module or run as a child process just by altering a configuration parameter. Anyway, thanks for your quick answer.
P.S. Problem identified: My box has a hardware issue - arrgl@x?!!***:(.

[nidibm]

@ibmmqmet i started consuming [email protected] but still i am hitting below error :
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR #
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR # Fatal error in , line 0
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR # Check failed: result.second.
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR #
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR #
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR #
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR #FailureMessage Object: 0x7fff49d36d50
2021-03-26T18:01:54.01+0530 [APP/PROC/WEB/0] ERR 1: 0x55920a70b291 [node]
2021-03-26T18:01:54.01+0530 [APP/PROC/WEB/0] ERR 2: 0x55920b87620e V8_Fatal(char const*, ...) [node]
2021-03-26T18:01:54.01+0530 [APP/PROC/WEB/0] ERR 3: 0x55920ab7ec7d v8::internal::GlobalBackingStoreRegistry::Register(std::shared_ptrv8::internal::BackingStore) [node]
2021-03-26T18:01:54.01+0530 [APP/PROC/WEB/0] ERR 4: 0x55920a86bd1e v8::ArrayBuffer::GetBackingStore() [node]
2021-03-26T18:01:54.02+0530 [APP/PROC/WEB/0] ERR 5: 0x55920a64e208 napi_get_typedarray_info [node]
2021-03-26T18:01:54.02+0530 [APP/PROC/WEB/0] ERR 6: 0x7f9cb45eb0ff [/home/vcap/deps/0/node_modules/ref-napi/prebuilds/linux-x64/node.napi.node]
2021-03-26T18:01:54.02+0530 [APP/PROC/WEB/0] ERR 7: 0x7f9cb45ed60b [/home/vcap/deps/0/node_modules/ref-napi/prebuilds/linux-x64/node.napi.node]
2021-03-26T18:01:54.02+0530 [APP/PROC/WEB/0] ERR 8: 0x7f9cb45f3d6b Napi::details::CallbackData<void ()(Napi::CallbackInfo const&), void>::Wrapper(napi_env__, napi_callback_info__*) [/home/vcap/deps/0/node_modules/ref-napi/prebuilds/linux-x64/node.napi.node]

[ibmmqmet]

All I can say is that my test programs started to succeed once I picked up the new version. Did you start with a clean directory where the newer version was installed into? Did you see the gcc compiles run during the installation? Could your enviornment be picking up an older level from somewhere?

[hellerim]

Hello Mark, as I wrote, there are improvements – the process which creates reply messages does not crash anymore when it tries repeatedly to put replies onto a dynamic queue which does not exist any longer. But activities such as opening and closing queues on the same connection frequently make my app still crash. Actually, it receives messages from a TCP connection, puts them onto one of two queues, an asynchronous one and a synchronous one, and collects replies from a dynamically created response queue which it writes back to the TCP socket. Also, after 20 minutes or so, a connection is closed and the corresponding client has to reconnect. To make my tests terminate within a reasonable time frame, I reduced this interval to 30 seconds up to a few minutes. The maximum number of successful reconnections was 5 and appears not to depend on the interval length. I tried with several concurrent TCP connections, and the application crashed after 3 to 6 connections. Starting a child process for each new TCP connection remedies the situation and represents a feasible solution in this case. I’m using the latest node version and installed the fixed version of ibmmq node.js the installation link to which you indicated in your note. Each time I update I delete the node_modules folder completely before. Kind regards, Goetz Von: Mark Taylor ***@***.***> Gesendet: Dienstag, 6. April 2021 14:14 An: ibm-messaging/mq-mqi-nodejs ***@***.***> Cc: hellerim ***@***.***>; Comment ***@***.***> Betreff: Re: [ibm-messaging/mq-mqi-nodejs] Getting error 0xbe52c6 v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [node] (#108) All I can say is that my test programs started to succeed once I picked up the new version. Did you start with a clean directory where the newer version was installed into? Did you see the gcc compiles run during the installation? Could your enviornment be picking up an older level from somewhere? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#108 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG2K5ERAUO2XCVP2QLWIW3THL3G3ANCNFSM4VE4NIUA> . <https://github.com/notifications/beacon/AAG2K5D6FR4PX6Y2KUINZPTTHL3G3A5CNFSM4VE4NIUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGCC3ZKA.gif>

[freerider7777]

I suddenly received such error (windows 10, node 14.18, ibmmq 0.9.18). Now updated to 0.9.19, continuing to monitor the problem...

#FailureMessage Object: 000000E50BAFD710
1: 00007FF7BCB3412F napi_wrap+133311
2: 00007FF7BCA5D13F std::basic_ostream<char,std::char_traits >::operator<<+57583
3: 00007FF7BD6CB6A2 V8_Fatal+162
4: 00007FF7BD1511DD v8::internal::BackingStore::Reallocate+653
5: 00007FF7BD398519 v8::ArrayBuffer::GetBackingStore+137
6: 00007FF7BCB101F9 napi_get_typedarray_info+393
7: 00007FFC83D78828
8: 00007FFC83D79F88
9: 00007FFC83D7F978
10: 00007FFC83D78063
11: 00007FFC83D7EFB3
12: 00007FF7BCB0AAC7 node::Stop+36375
13: 00007FF7BD35E9CF v8::internal::Builtins::builtin_handle+322591
14: 00007FF7BD35DF64 v8::internal::Builtins::builtin_handle+319924
15: 00007FF7BD35E258 v8::internal::Builtins::builtin_handle+320680
16: 00007FF7BD35E0A3 v8::internal::Builtins::builtin_handle+320243
17: 00007FF7BD43CEDD v8::internal::SetupIsolateDelegate::SetupHeap+474477
18: 00007FF7BD3D2FC2 v8::internal::SetupIsolateDelegate::SetupHeap+40530
19: 00007FF7BD3D2FC2 v8::internal::SetupIsolateDelegate::SetupHeap+40530
20: 00007FF7BD3D2FC2 v8::internal::SetupIsolateDelegate::SetupHeap+40530
21: 00007FF7BD3D0C7E v8::internal::SetupIsolateDelegate::SetupHeap+31502
22: 00007FF7BD3D086C v8::internal::SetupIsolateDelegate::SetupHeap+30460
23: 00007FF7BD2A09D2 v8::internal::Execution::CallWasm+1650
24: 00007FF7BD2A023F v8::internal::Execution::Call+191
25: 00007FF7BD099DE1 v8::internal::Object::SetProperty+2113
26: 00007FF7BD099938 v8::internal::Object::SetProperty+920
27: 00007FF7BD0994BD v8::internal::Object::SetProperty+77
28: 00007FF7BD1D6286 v8::internal::StubCache::Set+63494
29: 00007FF7BD1CF229 v8::internal::StubCache::Set+34729
30: 00007FF7BD43CDFD v8::internal::SetupIsolateDelegate::SetupHeap+474253
31: 00007FF7BD4B3ABE v8::internal::SetupIsolateDelegate::SetupHeap+960846
32: 00007FF7BD3D2FC2 v8::internal::SetupIsolateDelegate::SetupHeap+40530
33: 00007FF7BD3D2FC2 v8::internal::SetupIsolateDelegate::SetupHeap+40530
34: 00007FF7BD3D2FC2 v8::internal::SetupIsolateDelegate::SetupHeap+40530
35: 00000033CD0D2098
worker 193604 died

[ibmmqmet]

Current versions have stopped usnig the ffi dependencies.