error "write EINVAL"

[wenlonghuo]

• Version: 8.5.0,8.6.0
• Platform: windows10 64-bit 1703
• Subsystem:

while using child_process/spawn for ipc mode, child process will emit an error. it didn't appear in v8.4.0 or ubuntu

D:\fe\other\project\errortest>node index
hahah
events.js:182
      throw er; // Unhandled 'error' event
      ^

Error: write EINVAL
    at _errnoException (util.js:1019:11)
    at process.target._send (internal/child_process.js:704:20)
    at process.target.send (internal/child_process.js:588:19)
    at Object.<anonymous> (D:\fe\other\project\errortest\child.js:2:9)
    at Module._compile (module.js:624:30)
    at Object.Module._extensions..js (module.js:635:10)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)
    at Function.Module._load (module.js:500:3)
    at Function.Module.runMain (module.js:665:10)

file index.js

'use strict'
const spawn = require('child_process').spawn
const path = require('path')

let dir = path.join(__dirname, 'child.js')
let server = spawn('node', [`"${dir}"`], {
  stdio: ['pipe', 'ipc', 'pipe'],
  shell: true,
})
server.on('message', msg => {
  console.log(msg)
})

server.stderr.pipe(process.stderr)

file child.js

'use strict'
process.send('hahah')

[joyeecheung]

Couldn't reproduce on MacOS with v8.6.0 either. This is likely a Windows-specific issue

[vsemozhetbyt]

Can reproduce on Windows 7 x64 with Node.js 4.8.4, 6.11.3, 8.7.0, 9.0.0 (last Nightly of 2017-10-11)

[vsemozhetbyt]

cc @nodejs/platform-windows

[RReverser]

Windows 10 x64 - doesn't fail on 8.4.0, but throws on 8.6.0.

[bzoz]

This was introduced by #14791. It does not look related at all though.

[bzoz]

Moving the "instantiate eagerly" part to the end of startup() fixes this issue.

[bnoordhuis]

@bzoz With v8.6.0 too? The code from #14791 was removed in v8.6.0 in commit 8ce0e9a.

Semi-related: #16194

[bzoz]

It does reproduce on 8.7.0, 8ce0e9a and master

[bzoz]

This does not reproduce on neither Win 2012 nor 2008. It also does not happen on Win10 build 14393

[seishun]

The issue seems to be here:

node/deps/uv/src/win/pipe.c

Lines 1450 to 1458 in 8485a7c

	req->event_handle = CreateEvent(NULL, 0, 0, NULL);
	if (!req->event_handle) {
	uv_fatal_error(GetLastError(), "CreateEvent");
	}
	if (!RegisterWaitForSingleObject(&req->wait_handle,
	req->u.io.overlapped.hEvent, post_completion_write_wait, (void*) req,
	INFINITE, WT_EXECUTEINWAITTHREAD)) {
	return GetLastError();
	}

An event is created and assigned to req->event_handle, but then RegisterWaitForSingleObject is called with req->u.io.overlapped.hEvent instead which is always equal to zero due to memset in

node/deps/uv/src/win/pipe.c

Line 1250 in 8485a7c

memset(&req->u.io.overlapped, 0, sizeof(req->u.io.overlapped));

Unless I misunderstand something, this call to RegisterWaitForSingleObject will always fail.

[seishun]

But why is the UV_HANDLE_EMULATE_IOCP flag set? The CreateIoCompletionPort call on the IPC handle fails here:

node/deps/uv/src/win/pipe.c

Lines 303 to 308 in 8485a7c

	if (CreateIoCompletionPort(pipeHandle,
	loop->iocp,
	(ULONG_PTR)handle,
	0) == NULL) {
	handle->flags |= UV_HANDLE_EMULATE_IOCP;
	}

GetLastError() returns ERROR_INVALID_PARAMETER. Continuing investigation.

[seishun]

The reason this worked before #14791 is because _process.setupChannel() was called before NativeModule.require('console'). As a result, CreateIoCompletionPort succeeded for IPC but failed for stdout. But that's fine because the UV_HANDLE_EMULATE_IOCP flag is irrelevant for writing if UV_HANDLE_BLOCKING_WRITES is set.

Why does CreateIoCompletionPort fail when called on two different handles for the same fd? Who knows, might be a Windows bug. I couldn't find the Windows repo on GitHub so I can't submit an issue.

Moving _process.setupChannel() before setupGlobalConsole(); should fix the issue, but this seems very fragile. It's clear that libuv's handling of CreateIoCompletionPort failures is broken, but I'm not familiar enough with libuv to formulate an issue.

[seishun]

Here's a similar case that should fail with all Node.js versions:

index.js

const spawn = require('child_process').spawn
const path = require('path')

let dir = path.join(__dirname, 'child.js')
let server = spawn(process.argv0, [`"${dir}"`], {
  stdio: ['ipc', 'pipe', 'pipe'],
  shell: true,
})

server.stderr.pipe(process.stderr)

child.js

process.stdin.on('data', console.log);

I'm not sure this is something that can be fixed on Node.js/libuv's side at all.