Spawning child processes in bash on Windows can crash the parent process

[Morfent]

• Version: v7.1.0
• Platform: Linux OWNER43-PC 3.4.0+ deps: update openssl to 1.0.1j #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 x86_64 x86_64 x86_64 GNU/Linux, Windows 10 Pro
• Subsystem: child_process

I wrote a short piece of code to spawn a child process:

const {spawn} = require('child_process');

const sockets = spawn('go', ['run', 'sockets.go']);

That resulted in this error:

CRASH: Error: err >= 0
    at Object.exports._errnoException (util.js:1018:20)
    at exports._exceptionWithHostPort (util.js:1045:20)
    at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)

I tested the same piece of code on a FreeBSD 11.0 system using the same versions of bash, node, and go, which resulted in no crash, so I'm fairly sure the issue's in bash on Windows. Would there be a way to possibly mitigate this?

[steambap]

I have the same issue with exec of child_process.

• Version: v7.1.0
• Platform: Windows 10
• Subsystem: child_process

[killroy42]

I have this problem while executing webpack-dev-server as child process from within a node app.

[bnoordhuis]

I think your best bet is to report it to Microsoft. They've fixed similar issues in the recent past.

I'm going to close this out because it's not under our direct control but feel free to ask follow-up questions.

[killroy42]

Not sure this is a MS issue. To clarify, this is standard stuff, that works fine in 7.0.0 and broken in 7.1.0. This is both on Win10. My particular use-case was basically: child_process.spawn('webpack-dev-server.cmd ...')

[kayakyakr]

I've had a similar issue with multiple versions of node on WSL. Thought it was originally due to networking, but some of those syscalls have now been implemented. I'm going to go ahead and report it in the WSL issue tracker as well, but may need some help with figuring out what's going on. My issues are deep in the guts of ember-cli, bubbling out to net.js.

The strangest thing about this issue is it's not actually crashing on the error itself, it seems like it's crashing while trying to look up the error inside the uv library with Error: err >= 0. That's preventing the source error itself from being reported.

[kayakyakr]

Created an issue on libuv:
libuv/libuv#1137

And on windows bash:
microsoft/WSL#1354

[kayakyakr]

Update: uv on node 8.0.0 provides more information on what happened. I recommend installing the 8.0.0 nightly to see what syscall is failing and what the error code it returned is.