child_process.spawn() fails in 0.9.7 (all platforms)

[nponeccop]

Open node REPL, enter:

> require('child_process').spawn('jo')

0.8.x displays the result value and stays in REPL

0.9.x displays result value, then displays a stacktrace and exits REPL

Here is the trace:

events.js:69
        throw arguments[1]; // Unhandled 'error' event
                       ^
Error: read ENOTCONN
    at errnoException (net.js:847:11)
    at Socket._read (net.js:351:21)
    at Socket.Readable.read (_stream_readable.js:208:10)
    at Socket.read (net.js:249:43)
    at new Socket (net.js:172:10)
    at createSocket (child_process.js:63:11)
    at child_process.js:933:22
    at Array.forEach (native)
    at ChildProcess.spawn (child_process.js:922:9)
    at Object.exports.spawn (child_process.js:709:9)

Same error is displayed by node-gyp when it tries to build binary addons and runs reg.exe tool to read registry to detect installed compilers, so the problem is not specific to REPL.

[bnoordhuis]

/cc @piscisaureus and @sblom

[nponeccop]

Still happens in 0.9.9

[sblom]

@nponeccop, Is jo a command that exists in your path? I can reproduce your behavior when I try to invoke something that's not in my path, but it doesn't fail when spawn'd command is in my path.

Regardless, Node 0.9 shouldn't quit when you try to invoke a missing process, so I understand at least part of the work that I need to do here. The reg.exe failure has me worried that I don't fully understand all of the scenarios in play, though..

[nponeccop]

jo doesn't exist. The problem was mainly that "Node 0.9 shouldn't quit when you try to invoke a missing process".

I'll retest node-gyp more closely to see what's going on there.

Upd: I just checked and npm install xxhash fails with 0.9.7 but works with 0.9.9 so the most critical part of the bug has been fixed. I could successfully build xxhash binary addon with 0.9.9. So node-gyp part is not relevant anymore.

[sblom]

Just reproduced this on Mac OS with a rather different stack trace in latest master (0.9.10-pre):

events.js:69
        throw arguments[1]; // Unhandled 'error' event
                       ^
Error: spawn ENOENT
    at errnoException (child_process.js:922:11)
    at Process.ChildProcess._handle.onexit (child_process.js:713:34)
    at process._makeCallback (node.js:322:24)

Looks to me like Node 0.9 just isn't happy with trying to spawn non-existent processes, but in two different ways between Posix and Windows.

On Posix, spawn() complains. On Windows, a read(0) during socket creation for stdio complains.

[isaacs]

Fixed by #4780.

[alexlamsl]

Using 0.10.1 (and 0.10.0) on Windows XP, I still get this error:

C:\nodejs>node
> var spawn = require('child_process').spawn;
undefined
> spawn('git')
{ domain: null,
  _events: {},
  _maxListeners: 10,
  _closesNeeded: 1,
...
       _pendingEncoding: '' } ] }
>
events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: spawn ENOENT
    at errnoException (child_process.js:945:11)
    at Process.ChildProcess._handle.onexit (child_process.js:736:34)
C:\nodejs>

Similar to the cases reported by others, git is not present on this system.

[isaacs]

Install a newer version of git, which actually creates an EXE file.

[alexlamsl]

That's not the point - this system does not have git, which is very much intended.

With node.js 0.8.18/0.8.20, the same code survives and gives Error: 127 in the exit event.

[alexlamsl]

Perhaps I should make myself more clear - it is the termination of node.js which is the issue here, not the failure to spawn the non-existent executable.

[bnoordhuis]

Well, you're not catching the 'error' event so what do you expect? Try spawn('git').on('error', console.error)

[alexlamsl]

The existing code does try to catch it:

var spawn = require('child_process').spawn;
var git = spawn('git');
...
git.on('error', function (err) {
  ...
});

However, the node process quits before I can attach to the event.

Are we saying that this is now compulsory to chain-call on('error') immediately after spawn()?

Also, with 0.8 this is not an error, but is caught in exit event instead...

[alexlamsl]

OT: according to http://nodejs.org/api/child_process.html, error doesn't actually exist...

[alexlamsl]

@bnoordhuis your suggestion seems to have reliably fixed the issue I am seeing on 0.10.1, so thanks a lot!

[nponeccop]

The original issue I reported is still not fixed in 0.10.1: require('child_process').spawn('jo') terminates REPL with a stack trace if jo doesn't exist. When I type console.foo() it still displays a stacktrace but doesn't exit. Can the behavior be consistent so it either exits in both cases or catches errors in both cases?

Typing require('http').get('foo') exits too, so the 'problem' of inconsistency is not specific to child_process module. Is it really a problem? Should it be fixed? If not it worth documenting as REPLs failing on errors in entered code are pretty unusual.

[isaacs]

@nponeccop Throwing from async code still crashes the repl as of 0.10. In master, it's already changed to use a domain to prevent that from happening. However, this is a subtle and rather significant behavior change, so it's not something we can do in a stable release.