test: ensure existence of _handle property #5916

Trott · 2016-03-26T22:30:37Z

Pull Request check-list

Please make sure to review and check all of these items:

Does make -j8 test (UNIX) or vcbuild test nosign (Windows) pass with
this change (including linting)?
Is the commit message formatted according to [CONTRIBUTING.md][0]?
If this change fixes a bug (or a performance problem), is a regression
test (or a benchmark) included?
Is a documentation update included (if this change modifies
existing APIs, or introduces new ones)?

Affected core subsystem(s)

test

Description of change

test-stdtout-close-unref.js will fail if process.stdin._handle does
not exist. On UNIX-like operating systems, you can see this failure this
way:

./node test/parallel/test-stdout-close-unref.js < /dev/null

This issue has been experienced by @bengl and @drewfish in a Docker
container. I'm not sure why they are experiencing it in their
environment, but since it is possible that the _handle property does
not exist, perhaps it should be checked.

@nodejs/testing

drewfish · 2016-03-26T22:52:03Z

Thanks for the mention! Yes we're doing our jenkins builds inside of docker images. I'm running the tests using the test-ci makefile target.

(FWIW I've seen another case where node.js was being much more particular about IO streams than other languages.)

santigimeno · 2016-03-26T23:01:09Z

@Trott is there an issue opened for this? or a way to reproduce it? I have run the test suite on docker from time to time but never saw that error

Trott · 2016-03-26T23:05:54Z

@santigimeno It's not specific to Docker, although that might be a contributing factor. @bengl asked me about it today and I was able to reproduce the issue by using /dev/null as stdin like this:

./node test/parallel/test-stdout-close-unref.js  < /dev/null

Trott · 2016-03-26T23:07:12Z

Here's what the error looks like without this patch and using /dev/null for stdin as above:

/Users/node/test/parallel/test-stdout-close-unref.js:8
process.stdin._handle.close();
                     ^

TypeError: Cannot read property 'close' of undefined
    at Object.<anonymous> (/Users/node/test/parallel/test-stdout-close-unref.js:8:22)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:142:18)
    at node.js:939:3

jbergstroem · 2016-03-27T00:33:21Z

Holy crap; I've been seeing this in gentoo in a sandbox for years but couldn't figure out what was going on. Thanks 👍

https://github.com/gentoo/gentoo/blob/master/net-libs/nodejs/nodejs-5.9.0.ebuild#L71..L76

Trott · 2016-03-27T01:07:15Z

Alternate (perhaps better) solution might be to create a child process with an appropriate stdin and do everything there?

Fishrock123 · 2016-03-27T19:10:32Z

I'm pretty sure there is also an actual... API? issue here too.

I suppose the question would be, should process.stdin always have a ._handle property? I would think yes, but I'm not 100% sure.

<-ing a file into stdin actually results in a fs.ReadStream, rather an a tty.ReadStream, and as such does not inherit from net.Socket, unlike the other possible stdin options:

node/lib/internal/process/stdio.js

Lines 54 to 57 in 293fd04

    
           case 'FILE': 
        
             var fs = require('fs'); 
        
             stdin = new fs.ReadStream(null, { fd: fd, autoClose: false }); 
        
             break;

Trott · 2016-03-27T21:34:57Z

OK, I've updated the test so that it doesn't skip if there's no _handle property on process.stdin. Instead, it uses spawn() to set stdin to a pipe to make sure it has a _handle property. PTAL

If the current behavior is deemed a bug as @Fishrock123 seems to suggest, then we can put a version of this test in known_issues that sets stdio to ignore rather than pipe and that will detect the issue.

In the meantime, here's a version of the test that should always pass.

Fishrock123 · 2016-03-28T15:04:19Z

I'm not sure if it is a bug so much as a possible API deficiency. I guess you could just write it off as an oddity but that seems pretty ... not-good to me, although I'm not really sure how to fix it either.

CI: https://ci.nodejs.org/job/node-test-pull-request/2080/

Fishrock123 · 2016-03-28T15:26:36Z

I've made a PR for the known issue at #5935

Trott · 2016-03-28T18:41:41Z

The single CI failure appears to be known-flaky and unrelated.

Fishrock123 · 2016-03-28T21:35:04Z

lgtm

Trott · 2016-03-28T21:44:13Z

Any chance we can get a quick confirmation from @drewfish or @bengl that this new patch fixes the test for them? (Because if it doesn't, that's going to be really puzzling...)

bengl · 2016-03-28T21:56:59Z

Giving it a go. Back soon with results.

mhdawson · 2016-03-28T22:09:50Z

Good to see this being fixed. The suse build team for PPC was also seeing this failure and I was working with them to try and figure out why.

bengl · 2016-03-28T22:46:59Z

Yep. Fixes the test for us.

drewfish · 2016-03-28T23:09:30Z

@jbergstroem do you happen to have also seen failures of test-cluster-master-error.js and test-cluster-master-kill.js? Given that you saw the test-stdtout-close-unref failure as well I thought I'd see how common these other two are before I dig into them.

Fishrock123 · 2016-03-30T16:56:51Z

test/parallel/test-stdout-close-unref.js

+
+proc.on('exit', common.mustCall(function(exitCode) {
+  assert.equal(exitCode, 0);
+}));


I suggest doing the following instead:

proc.stderr.pipe(process.stderr); proc.on('exit', common.mustCall(function(exitCode) { process.exitCode = exitCode; }));

This way, you can see the child's error, and not need to generate a second error on the parent.

... What I'm going to be doing for TTY testing in #5834 :)

@Fishrock123 Ooh, yes, neat, will do. (I'm going to use process.exit(...) instead of process.exitCode = ... there if it's all the same to you.)

jbergstroem · 2016-03-30T22:09:57Z

@drewfish sorry for the late response -- I swear I replied (this is the second time I've seen this happen; watching you github!). Anyway, haven't seen any issues with those tests from the gentoo sandbox.

Trott · 2016-03-30T23:12:31Z

Whoops, pushed the wrong version, let's try again. Updated, PTAL.

CI: https://ci.nodejs.org/job/node-test-pull-request/2103/

Trott · 2016-03-31T02:58:27Z

CI is being uncooperative. Let's CI again: https://ci.nodejs.org/job/node-test-pull-request/2105/

Trott · 2016-03-31T16:33:42Z

Well, it was more cooperative that time, but still one host hung while building or something. So let's do it again, because hey, I like my CI green: https://ci.nodejs.org/job/node-test-pull-request/2112/

Trott · 2016-03-31T16:34:43Z

@Fishrock123 Your LGTM still stands?

Fishrock123 · 2016-03-31T16:36:29Z

test/parallel/test-stdout-close-unref.js

+
+proc.stderr.pipe(process.stderr);
+proc.on('exit', common.mustCall(function(exitCode) {
+  process.exit(exitCode);


I would probably make this just set the process.exitCode, rather than exit().

exit() is a bit ... expedited ... and can cause unwanted things. :)

@Fishrock123 I suppose so. I did that instead of setting process.exitCode because setting the exit code but doing nothing else is kind of magical and also leaves open the possibility of someone adding a test to this file later on that does the same thing, thus overriding the exit code here. I'm probably overthinking it, though. Will switch to your recommendation.

Fishrock123 · 2016-03-31T16:36:38Z

lgtm otherwise

`<`-ing a file into stdin actually results in a `fs.ReadStream`, rather than a `tty.ReadStream`, and as such does not inherit from net.Socket, unlike the other possible stdin options. Refs: nodejs#5916 PR-URL: nodejs#5935 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

@bengl

`test-stdtout-close-unref.js` will fail if `process.stdin._handle` does not exist. On UNIX-like operating systems, you can see this failure this way: ./node test/parallel/test-stdout-close-unref.js < /dev/null This issue has been experienced by @bengl and @drewfish in a Docker container. I'm not sure why they are experiencing it in their environment, but since it is possible that the `_handle` property does not exist, let's use `child_process.spawn()` to make sure it exists.

Trott · 2016-03-31T23:34:30Z

Updated to use process.exitCode if the spawned process exits with a non-zero code.

Trott · 2016-03-31T23:35:22Z

CI for good measure: https://ci.nodejs.org/job/node-test-pull-request/2116/

@bengl

`test-stdtout-close-unref.js` will fail if `process.stdin._handle` does not exist. On UNIX-like operating systems, you can see this failure this way: ./node test/parallel/test-stdout-close-unref.js < /dev/null This issue has been experienced by @bengl and @drewfish in a Docker container. I'm not sure why they are experiencing it in their environment, but since it is possible that the `_handle` property does not exist, let's use `child_process.spawn()` to make sure it exists. PR-URL: nodejs#5916 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

Trott · 2016-04-01T03:10:22Z

Landed in a20c700

`<`-ing a file into stdin actually results in a `fs.ReadStream`, rather than a `tty.ReadStream`, and as such does not inherit from net.Socket, unlike the other possible stdin options. Refs: #5916 PR-URL: #5935 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

@bengl

`test-stdtout-close-unref.js` will fail if `process.stdin._handle` does not exist. On UNIX-like operating systems, you can see this failure this way: ./node test/parallel/test-stdout-close-unref.js < /dev/null This issue has been experienced by @bengl and @drewfish in a Docker container. I'm not sure why they are experiencing it in their environment, but since it is possible that the `_handle` property does not exist, let's use `child_process.spawn()` to make sure it exists. PR-URL: #5916 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

@bengl

`test-stdtout-close-unref.js` will fail if `process.stdin._handle` does not exist. On UNIX-like operating systems, you can see this failure this way: ./node test/parallel/test-stdout-close-unref.js < /dev/null This issue has been experienced by @bengl and @drewfish in a Docker container. I'm not sure why they are experiencing it in their environment, but since it is possible that the `_handle` property does not exist, let's use `child_process.spawn()` to make sure it exists. PR-URL: #5916 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

`<`-ing a file into stdin actually results in a `fs.ReadStream`, rather than a `tty.ReadStream`, and as such does not inherit from net.Socket, unlike the other possible stdin options. Refs: #5916 PR-URL: #5935 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

Trott added test Issues and PRs related to the tests. process Issues and PRs related to the process subsystem. labels Mar 26, 2016

Trott force-pushed the bengie branch from 23074bf to 45acade Compare March 26, 2016 22:38

Fishrock123 mentioned this pull request Mar 27, 2016

Piping from stdin is broken #5927

Closed

Trott force-pushed the bengie branch from 45acade to 0b7bfdd Compare March 27, 2016 21:17

Fishrock123 mentioned this pull request Mar 28, 2016

test: stdin is not always a net.Socket #5935

Merged

2 tasks

Fishrock123 reviewed Mar 30, 2016
View reviewed changes

Trott force-pushed the bengie branch 3 times, most recently from bc85d46 to b808952 Compare March 30, 2016 23:11

Trott changed the title ~~test: skip test if no _handle property~~ test: ensure existence of _handle property Mar 30, 2016

Fishrock123 reviewed Mar 31, 2016
View reviewed changes

Trott force-pushed the bengie branch from b808952 to fa8f31f Compare March 31, 2016 23:34

Trott added the lts-watch-v4.x label Apr 1, 2016

Trott closed this Apr 1, 2016

This was referenced Apr 5, 2016

V5.10.1 proposal #6059

Closed

V5.10.1 proposal #6060

Merged

MylesBorins added land-on-v4.x and removed lts-watch-v4.x labels Apr 11, 2016

MylesBorins mentioned this pull request Apr 11, 2016

V4.4.3 proposal #6149

Merged

STRML mentioned this pull request Jan 9, 2017

uws: Cannot read property 'fd' of null primus/primus#530

Closed

danbev mentioned this pull request Oct 22, 2017

test: make test-v8-serdes work without stdin #16382

Closed

2 tasks

Trott deleted the bengie branch January 13, 2022 22:42

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

test: ensure existence of _handle property #5916

test: ensure existence of _handle property #5916

Trott commented Mar 26, 2016

drewfish commented Mar 26, 2016

santigimeno commented Mar 26, 2016

Trott commented Mar 26, 2016

Trott commented Mar 26, 2016

jbergstroem commented Mar 27, 2016

Trott commented Mar 27, 2016

Fishrock123 commented Mar 27, 2016

Trott commented Mar 27, 2016

Fishrock123 commented Mar 28, 2016

Fishrock123 commented Mar 28, 2016

Trott commented Mar 28, 2016

Fishrock123 commented Mar 28, 2016

Trott commented Mar 28, 2016

bengl commented Mar 28, 2016

mhdawson commented Mar 28, 2016

bengl commented Mar 28, 2016

drewfish commented Mar 28, 2016

Fishrock123 Mar 30, 2016

Trott Mar 30, 2016

jbergstroem commented Mar 30, 2016

Trott commented Mar 30, 2016

Trott commented Mar 31, 2016

Trott commented Mar 31, 2016

Trott commented Mar 31, 2016

Fishrock123 Mar 31, 2016

Trott Mar 31, 2016

Fishrock123 commented Mar 31, 2016

Trott commented Mar 31, 2016

Trott commented Mar 31, 2016

Trott commented Apr 1, 2016

test: ensure existence of _handle property #5916

test: ensure existence of _handle property #5916

Conversation

Trott commented Mar 26, 2016

Pull Request check-list

Affected core subsystem(s)

Description of change

drewfish commented Mar 26, 2016

santigimeno commented Mar 26, 2016

Trott commented Mar 26, 2016

Trott commented Mar 26, 2016

jbergstroem commented Mar 27, 2016

Trott commented Mar 27, 2016

Fishrock123 commented Mar 27, 2016

Trott commented Mar 27, 2016

Fishrock123 commented Mar 28, 2016

Fishrock123 commented Mar 28, 2016

Trott commented Mar 28, 2016

Fishrock123 commented Mar 28, 2016

Trott commented Mar 28, 2016

bengl commented Mar 28, 2016

mhdawson commented Mar 28, 2016

bengl commented Mar 28, 2016

drewfish commented Mar 28, 2016

Fishrock123 Mar 30, 2016

Choose a reason for hiding this comment

Trott Mar 30, 2016

Choose a reason for hiding this comment

jbergstroem commented Mar 30, 2016

Trott commented Mar 30, 2016

Trott commented Mar 31, 2016

Trott commented Mar 31, 2016

Trott commented Mar 31, 2016

Fishrock123 Mar 31, 2016

Choose a reason for hiding this comment

Trott Mar 31, 2016

Choose a reason for hiding this comment

Fishrock123 commented Mar 31, 2016

Trott commented Mar 31, 2016

Trott commented Mar 31, 2016

Trott commented Apr 1, 2016