Hello, I have this error message when starting my homebridge after the update from node 8.4.0 on node 8.6.0.
Does anyone know this error?
Okt 01 17:49:45 Server homebridge[2323]: /usr/local/bin/node[2323]: ../src/cares_wrap.cc:1944:void node::cares_wrap::{anonymous}::GetAddrInfo(const v8::FunctionCallbackInfo
Can you narrow it down (code-wise) as much as possible so we can find out why the assertion is failing?
I'm going to guess that something in homebridge or a homebridge plugin uses node internals directly.
If you install llnode, you should be able to obtain a stack trace (including C++ and JS stack frames) in lldb. That should tell you where the call came from.
edit: in case it matters: #14731 is the change that introduced the boolean.
Ok I think I found the culprit after some quick digging: homebridge uses hap-nodejs which uses mdns which uses process.binding('cares_wrap') to access the internals. On the mdns repo there is already the same issue reported there. So it sounds like mdns needs to fix things on their end in one way or another.
Same error...
/home/admin/.nvm/versions/node/v8.6.0/bin/node[14333]: ../src/cares_wrap.cc:1944:void node::cares_wrap::{anonymous}::GetAddrInfo(const v8::FunctionCallbackInfo
1: node::Abort() [node]
2: node::Assert(char const* const () [4]) [node]
3: 0x133cb41 [node]
4: v8::internal::FunctionCallbackArguments::Call(void ()(v8::FunctionCallbackInfo
5: 0xc13f5a [node]
6: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object*, v8::internal::Isolate) [node]
7: 0x2a5e83a046fd
[admin@localhost simple-service]$ node -v
v8.6.0
More info:
0 info it worked if it ends with ok
1 verbose cli [ '/home/admin/.nvm/versions/node/v8.6.0/bin/node',
1 verbose cli '/home/admin/.nvm/versions/node/v8.6.0/bin/npm',
1 verbose cli 'start' ]
2 info using [email protected]
3 info using [email protected]
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle [email protected]~prestart: [email protected]
6 info lifecycle [email protected]~start: [email protected]
7 verbose lifecycle [email protected]~start: unsafe-perm in lifecycle true
8 verbose lifecycle [email protected]~start: PATH: /home/admin/.nvm/versions/node/v8.6.0/lib/node_modules/npm/bin/node-gyp-bin:/home/admin/Documents/UnitLabs/other_implementations/nod$
9 verbose lifecycle [email protected]~start: CWD: /home/admin/Documents/UnitLabs/other_implementations/node/simple-service
10 silly lifecycle [email protected]~start: Args: [ '-c', 'node server.js' ]
11 silly lifecycle [email protected]~start: Returned: code: 1 signal: null
12 info lifecycle [email protected]~start: Failed to exec start script
13 verbose stack Error: [email protected] start: node server.js
13 verbose stack Exit status 1
13 verbose stack at EventEmitter.
13 verbose stack at emitTwo (events.js:125:13)
13 verbose stack at EventEmitter.emit (events.js:213:7)
13 verbose stack at ChildProcess.
13 verbose stack at emitTwo (events.js:125:13)
13 verbose stack at ChildProcess.emit (events.js:213:7)
13 verbose stack at maybeClose (internal/child_process.js:927:16)
13 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
14 verbose pkgid [email protected]
15 verbose cwd /home/admin/Documents/UnitLabs/other_implementations/node/simple-service
16 verbose Linux 3.10.0-693.2.2.el7.x86_64
17 verbose argv "/home/admin/.nvm/versions/node/v8.6.0/bin/node" "/home/admin/.nvm/versions/node/v8.6.0/bin/npm" "start"
18 verbose node v8.6.0
19 verbose npm v5.5.1
20 error code ELIFECYCLE
21 error errno 1
22 error [email protected] start: node server.js
22 error Exit status 1
23 error Failed at the [email protected] start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]
@nmpribeiro Can you open an issue at https://github.com/nodejs/help? Like @mscdex said above, this kind of error points to something being wrong with your code or your dependencies, not with Node itself.
Ho yes, sorry! I wanted to post this info on the proper package. Disregard please!
@addaleax thanks
Most helpful comment
Ok I think I found the culprit after some quick digging:
homebridgeuseshap-nodejswhich usesmdnswhich usesprocess.binding('cares_wrap')to access the internals. On themdnsrepo there is already the same issue reported there. So it sounds likemdnsneeds to fix things on their end in one way or another.