Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: only check fd 0,1,2 are used and not their access modes #10339

Closed
wants to merge 1 commit into from

Conversation

jBarz
Copy link
Contributor

@jBarz jBarz commented Dec 19, 2016

Don't do a write on stdout/stderr because that checks for their
writability. But fd=1 could legitimately be opened with read-only access by the user.
What this test needs to only ensure is that they are used at startup.

Checklist
  • make -j4 test (UNIX)
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

test

Description of change

Fixes: #10234

@nodejs-github-bot nodejs-github-bot added test Issues and PRs related to the tests. lts-watch-v6.x labels Dec 19, 2016
Copy link
Contributor

@sam-github sam-github left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a good approach to me.

process.exit(84);
}
});
fs.fstatSync(1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should check 0 as well (the original didn't, possibly because its hard to do if input is unavailable).

@jBarz jBarz force-pushed the aix-stdio-closed.2 branch from dbd9df8 to 3c49228 Compare December 19, 2016 16:03
@jBarz jBarz force-pushed the aix-stdio-closed.2 branch from 3c49228 to 76773e2 Compare December 19, 2016 16:04
@jBarz jBarz changed the title test: only check that fd 1,2 are used and not their access modes test: only check fd 0,1,2 are used and not their access modes Dec 19, 2016
@mscdex mscdex added the child_process Issues and PRs related to the child_process subsystem. label Dec 19, 2016
Copy link
Member

@gibfahn gibfahn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you make the first line of the commit message <50 chars?

While you're at it, you can add this to the commit:


Fixes: https://github.com/nodejs/node/issues/10234

@jBarz
Copy link
Contributor Author

jBarz commented Dec 19, 2016

Fixed first line of commit message and added following
Fixes #10234

Copy link
Member

@gibfahn gibfahn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Fishrock123
Copy link
Contributor

Is the original behavior good to preserve for non-AIX platforms in a different test case?

I think this follows the test name but has fundamentally different behavior.

@jBarz
Copy link
Contributor Author

jBarz commented Dec 19, 2016

IMO, we don't need to preserve the original behavior because on any system, fd=1 doesn't have to be writable. So the original test-case was making an incorrect assumption.

@sam-github
Copy link
Contributor

The original test was asserting things that b5f25a9 did not in fact guarantee. What b5f25a9 did do is described as

Check that stdin, stdout and stderr map to open file descriptors

However, the test checked that stdout and stderr were writeable (something the c++ code does not check), and didn't do any check at all for stdin. This version of the test asserts that 0,1,2 map to open fds, which is exactly what is intended, and does it using fstat(), which is exactly what the code-under-test does:

node/src/node.cc

Line 4058 in 5d14602

if (fstat(fd, &ignored) == 0)

Seems perfect to me.

} catch (e) {
assert.strictEqual(e.code, 'EBADF');
assert.strictEqual(e.message, 'EBADF: bad file descriptor, write');
process.exit(126);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is being rewritten anyway, rather than try-catch could it instead be using assert.doesNotThrow? I'm also personally not a fan of the magic process exit values (42 and 126) -- Doesn't an uncaught assertion failure cause a non-zero exit code which we can check in the parent?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it does, status is 1 on uncaught exception

@gibfahn
Copy link
Member

gibfahn commented Dec 19, 2016

cc/ @sxa555 @Trott @nodejs/platform-aix for review

assert.doesNotThrow(function() {
fs.fstatSync(2)
});
return 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 0 is unnecessary here.

@gibfahn gibfahn self-assigned this Jan 23, 2017
@gibfahn
Copy link
Member

gibfahn commented Jan 23, 2017

Another CI just to confirm: https://ci.nodejs.org/job/node-test-commit/7423/

});
assert.doesNotThrow(function() {
fs.fstatSync(2)
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extremely minor nit... this can be much more succinctly written...

[0,1,2].forEach((i) => assert.doesNotThrow(() => fs.fstatSync(i)));

But not necessary to land :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will land. I like succinctness :-)

Don't do a write on stdout/stderr because that checks for their
writability. But fd=1 could legitimately be opened with read-only
access by the user. What this test needs to only ensure is that
they are used at startup.
This fixes nodejs#10234
@gibfahn
Copy link
Member

gibfahn commented Jan 23, 2017

CI: https://ci.nodejs.org/job/node-test-commit/7430/

EDIT: Windows job is hanging, looks like a machine issue, otherwise good.

@gibfahn
Copy link
Member

gibfahn commented Jan 23, 2017

Landed in 106d09a

@gibfahn gibfahn closed this Jan 23, 2017
gibfahn pushed a commit that referenced this pull request Jan 23, 2017
Don't do a write on stdout/stderr because that checks for their
writability. But fd=1 could legitimately be opened with read-only
access by the user. All this test needs to ensure is that
they are used at startup.

PR-URL: #10339
Fixes: #10234
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
@jBarz jBarz deleted the aix-stdio-closed.2 branch January 23, 2017 20:04
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 25, 2017
Don't do a write on stdout/stderr because that checks for their
writability. But fd=1 could legitimately be opened with read-only
access by the user. All this test needs to ensure is that
they are used at startup.

PR-URL: nodejs#10339
Fixes: nodejs#10234
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 27, 2017
Don't do a write on stdout/stderr because that checks for their
writability. But fd=1 could legitimately be opened with read-only
access by the user. All this test needs to ensure is that
they are used at startup.

PR-URL: nodejs#10339
Fixes: nodejs#10234
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
@italoacasas italoacasas mentioned this pull request Jan 29, 2017
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 30, 2017
Don't do a write on stdout/stderr because that checks for their
writability. But fd=1 could legitimately be opened with read-only
access by the user. All this test needs to ensure is that
they are used at startup.

PR-URL: nodejs#10339
Fixes: nodejs#10234
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 30, 2017
Don't do a write on stdout/stderr because that checks for their
writability. But fd=1 could legitimately be opened with read-only
access by the user. All this test needs to ensure is that
they are used at startup.

PR-URL: nodejs#10339
Fixes: nodejs#10234
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit that referenced this pull request Mar 8, 2017
Don't do a write on stdout/stderr because that checks for their
writability. But fd=1 could legitimately be opened with read-only
access by the user. All this test needs to ensure is that
they are used at startup.

PR-URL: #10339
Fixes: #10234
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit that referenced this pull request Mar 8, 2017
Don't do a write on stdout/stderr because that checks for their
writability. But fd=1 could legitimately be opened with read-only
access by the user. All this test needs to ensure is that
they are used at startup.

PR-URL: #10339
Fixes: #10234
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit that referenced this pull request Mar 9, 2017
Don't do a write on stdout/stderr because that checks for their
writability. But fd=1 could legitimately be opened with read-only
access by the user. All this test needs to ensure is that
they are used at startup.

PR-URL: #10339
Fixes: #10234
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Mar 9, 2017
MylesBorins pushed a commit that referenced this pull request Mar 9, 2017
Don't do a write on stdout/stderr because that checks for their
writability. But fd=1 could legitimately be opened with read-only
access by the user. All this test needs to ensure is that
they are used at startup.

PR-URL: #10339
Fixes: #10234
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Mar 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
child_process Issues and PRs related to the child_process subsystem. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

test-stdio-closed failing on some AIX environments