Node: Error in TCPWrap: Assertion `args[0]->IsInt32()' failed

Created on 26 Jan 2018  Β·  6Comments  Β·  Source: nodejs/node

  • Version: v9.4.0
  • Platform: Linux arch 4.14.15-1-ARCH #1 SMP PREEMPT Tue Jan 23 21:49:25 UTC 2018 x86_64 GNU/Linux
  • Subsystem:

Running node server, sometimes I get the following error:

/usr/bin/node[25812]: ../src/tcp_wrap.cc:145:static void node::TCPWrap::New(const v8::FunctionCallbackInfo&): Assertion `args[0]->IsInt32()' failed.
1: node::Abort() [/usr/bin/node]
2: 0x55a03978915b [/usr/bin/node]
3: node::TCPWrap::New(v8::FunctionCallbackInfo const&) [/usr/bin/node]
4: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo const&)) [/usr/bin/node]
5: 0x55a0390e5955 [/usr/bin/node]
6: 0x55a0390e624a [/usr/bin/node]
7: 0x2afb5b0842fd

I recently upgraded sequelize and pg versions (along with a bunch of other libraries), so it might be related.
Is there a way to provide more detailed stacktrace ?

Most helpful comment

In case anyone else with the same problem is reading, what I ended up doing was to use the "dedicated-process" strategy of phantom-html-to-pdf package, which doesn't make use of the phantom-workers dependency (the one which finally depends on net-cluster).

All 6 comments

Could you run search your node_modules folder for the string process.binding? My first guess would be a dependency of your project is relying on Node’s internals, so you’d need to contact them about it.

Is there a way to provide more detailed stacktrace ?

If you can reproduce this reliably, you could run Node inside llnode as a debugger and run v8 bt at the crash site to get a JS stack trace.

If not, you could try to get a core dump and open that in the debugger.

(This was likely caused by b44efded84818, but as mentioned the bug probably isn’t in Node.)

Hi @addaleax ! Thanks for the quick replu.
Running grep -lR "process.binding" yields:

express-session/node_modules/debug/src/node.js
compression/node_modules/debug/src/node.js
execa/lib/errname.js
core-util-is/float.patch
natives/index.js
portscanner/node_modules/async/test/test-async.js
ejs/ejs.js
ejs/ejs.min.js
net-cluster/lib/net-cluster.js
net-cluster/src/net-cluster.coffee
debug/src/node.js
morgan/node_modules/debug/src/node.js
builtin-modules/index.js
ajv/dist/nodent.min.js
ajv/dist/regenerator.min.js
send/node_modules/debug/src/node.js
finalhandler/node_modules/debug/src/node.js
body-parser/node_modules/debug/src/node.js
wkx/dist/wkx.min.js
wkx/dist/wkx.js
retry-as-promised/node_modules/debug/src/node.js
pac-proxy-agent/node_modules/debug/src/node.js
mammoth/mammoth.browser.js
mammoth/mammoth.browser.min.js
express/node_modules/debug/src/node.js

And running: grep -R "process.binding" | grep "tcp_wrap"

net-cluster/lib/net-cluster.js:  TCP = process.binding("tcp_wrap").TCP;
net-cluster/src/net-cluster.coffee:{TCP} = process.binding "tcp_wrap"

Is this one the culprit ? I will now try to obtain a JS stack trace.

Running npm ls | grep -B 5 -A 10 net-cluster I get:

β”œβ”€β”¬ [email protected]
β”‚ β”œβ”€β”€ [email protected]
β”‚ β”œβ”€β”€ [email protected]
β”‚ β”œβ”€β”€ [email protected]
β”‚ β”œβ”€β”¬ [email protected]
β”‚ β”‚ β”œβ”€β”€ [email protected]
β”‚ β”‚ β”œβ”€β”€ [email protected]
β”‚ β”‚ β”œβ”€β”¬ [email protected]
β”‚ β”‚ β”‚ β”œβ”€β”€ [email protected] deduped
β”‚ β”‚ β”‚ β”œβ”€β”¬ [email protected]
β”‚ β”‚ β”‚ β”‚ β”œβ”€β”¬ [email protected]
β”‚ β”‚ β”‚ β”‚ β”‚ └── [email protected] deduped
β”‚ β”‚ β”‚ β”‚ β”œβ”€β”€ [email protected] deduped
β”‚ β”‚ β”‚ β”‚ └── [email protected] deduped
β”‚ β”‚ β”‚ β”œβ”€β”€ [email protected] deduped
β”‚ β”‚ β”‚ β”œβ”€β”¬ [email protected]

And this is the only appearance of net-cluster

@FlyingPumba Yup, it looks like that module is the one that’s broken. Given that that module has not been maintained for 5 years and the maintainer doesn’t seem very active (but ping @supershabam anyway), I think the main options are:

  • Look into removing it out of the dependency chain, i.e. remove it as a dependency of phantom-workers; or
  • Rewrite it so that it doesn’t rely on Node’s internals, publish that as a new module, then make phantom-workers use that one

@addaleax Thanks!
I'll see what I can do. I might be able to replace phantom-html-to-pdf package completely by html-pdf, which looks like a more mature library.

In case anyone else with the same problem is reading, what I ended up doing was to use the "dedicated-process" strategy of phantom-html-to-pdf package, which doesn't make use of the phantom-workers dependency (the one which finally depends on net-cluster).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

seishun picture seishun  Β·  3Comments

vsemozhetbyt picture vsemozhetbyt  Β·  3Comments

Brekmister picture Brekmister  Β·  3Comments

mcollina picture mcollina  Β·  3Comments

danialkhansari picture danialkhansari  Β·  3Comments