Setting callback for on 'data' event of stderr causes error on v10.0.0

[jesobreira]

• Version: 10.0.0
• Platform: OS X 10.13.2
• Subsystem: Process

I am unable to set a callback on the 'data' event (since process.stderr is a net.Socket stream, it should emit the data event).

The following snippet works on v8.0.0 but throws an error on v10.0.0:

process.stderr.on('data', function(data) {
    // not relevant, error is threw anyway
});

Error threw:

Error: read ENOTCONN
    at WriteStream.Socket._read (net.js:530:20)
    at WriteStream.Readable.read (_stream_readable.js:458:10)
    at resume_ (_stream_readable.js:897:12)
    at process._tickCallback (internal/process/next_tick.js:174:19)
    at Function.Module.runMain (internal/modules/cjs/loader.js:721:11)
    at startup (internal/bootstrap/node.js:228:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:575:3)
Emitted 'error' event at:
    at emitErrorNT (internal/streams/destroy.js:92:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
    at process._tickCallback (internal/process/next_tick.js:174:19)
    [... lines matching original stack trace ...]
    at bootstrapNodeJSCore (internal/bootstrap/node.js:575:3)

[ryzokuken]

Okay, it doesn't throw on Node 8 and throws on 10.

/cc @nodejs/process @nodejs/streams

[ryzokuken]

Even if it's a valid error, we should try throwing something descriptive.

[mcollina]

This is likely a bug on stdout/stderr and net, and not on stream.

[jrasanen]

I git bisected when the error was introduced, if that helps (this commit):

ae2b5bcb7c17a2d2a488f234c736201eed8200db is the first bad commit
commit ae2b5bcb7c17a2d2a488f234c736201eed8200db
Author: cjihrig <cjihrig@gmail.com>
Date:   Mon Apr 2 13:33:48 2018 -0400

    deps: upgrade libuv to 1.20.0

    Notable changes:
    - uv_fs_copyfile() adds support for copy-on-write behavior.
    - uv_relative_path() now uses the long directory name
      for handle->dirw.
    - File operations on files > 2 GB on 32-bit platforms are
      working again.
    - uv_fs_fchmod() on Windows works on files with the
      Archive flag cleared.

    Fixes: https://github.com/nodejs/node/issues/19170
    Fixes: https://github.com/nodejs/node/issues/19455
    Fixes: https://github.com/nodejs/node/issues/12803
    PR-URL: https://github.com/nodejs/node/pull/19758
    Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
    Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
    Reviewed-By: James M Snell <jasnell@gmail.com>

:040000 040000 b5f3cc6178caf6ee1a46ee21fc89c83b2b32a69c c093efd2a818669a8aa2d3641905d6cf2e432c30 M	deps

[cjihrig]

The specific commit in libuv responsible for this is libuv/libuv@8f9ba2a. Specifically, the return -ENOTCONN; when uv_read_start() is called on a stream that is not readable.

This breakage was not intended, but this is arguably a bug in Node (or the application code) as the socket's readable property is false.

[thatshailesh]

Hi All, would like to work on this need some guidance, as per comments i think this hasn't been fixed yet please let me know if this still need to fixed for me to proceed :)

[AyushG3112]

Same issue exists with v10.5.0 and stdout

process.stdout.on('data', function(data) {
    
});

[AyushG3112]

Resolving issue is more complicated than it seemed at first glance(atleast to me), but the gist of the issue is is the stdout or stderrs fd handle type corresponds to TTY, PIPE or TCP, the stream is created as a WriteStream instead of a DuplexStream.

Relevant code is at:

node/lib/internal/process/stdio.js

Lines 164 to 197 in cdb5985

	function createWritableStdioStream(fd) {
	var stream;
	const tty_wrap = process.binding('tty_wrap');
	// Note stream._type is used for test-module-load-list.js
	switch (tty_wrap.guessHandleType(fd)) {
	case 'TTY':
	var tty = require('tty');
	stream = new tty.WriteStream(fd);
	stream._type = 'tty';
	break;
	case 'FILE':
	const SyncWriteStream = require('internal/fs/sync_write_stream');
	stream = new SyncWriteStream(fd, { autoClose: false });
	stream._type = 'fs';
	break;
	case 'PIPE':
	case 'TCP':
	var net = require('net');
	stream = new net.Socket({
	fd: fd,
	readable: false,
	writable: true
	});
	stream._type = 'pipe';
	break;
	default:
	// Probably an error on in uv_guess_handle()
	throw new ERR_UNKNOWN_STREAM_TYPE();
	}

[IamManchanda]

V

…

On Sun, Jun 24, 2018, 5:08 PM Ayush Gupta ***@***.***> wrote: Found the issue, PR coming in a bit if the fix works. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21203 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEvYgA23bcuvV_aHIdWKVgiYpePFDMAvks5t_3o_gaJpZM4UfUp1> .