-
Notifications
You must be signed in to change notification settings - Fork 29.1k
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: Allow all valid AIX rc in test-stdio-closed #10239
Conversation
Fixes: nodejs#10234 Allow either of the two possible return codes on AIX to be considered successful on test-stdio-closed.js
LGTM, to get things stable. The test could use a comment on what it is testing, but I I wonder if the test would be more robust if instead of calling /cc @bnoordhuis |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully only an interim solution, but LGTM as both results comply with spec, as far as I am able to tell.
@Trott 126 means stdout had a EBADF, which means its not working as intended, b5f25a9 is supposed to replace EBADF descriptors with a new descriptor open on I guess there is no way to just mark a test as skipped, so its more clearly something to come back to later? |
@sam-github Not working as the Node.js code expects, but working in a correct fashion nonetheless. At least, that's my interpretation. Correction welcome. It seems to me that Node.js is trying to take advantage of a behavior that is permitted on other operating systems, but is not the only correct behavior. |
@sam-github To get a little more specific about my understanding (and hopefully not my misunderstanding) about this issue: Node.js attempts to re-open the EBADF fd on /dev/null. POSIX allows the operating system to permit opening the closed stdio fd on /dev/null, but it does not require the operating system to permit it. So the test should accommodate the unexpected-by-Node.js behavior on AIX, at least as a minimal workaround. (I'm certainly open to more robust solutions that might involve either addressing the issue on the C++ side or finding a way for the test to query the operating system ahead of time to see what the expected result should be.) |
@sam-github wrote:
I think we could do something like this perhaps: if (common.isAix and exitCode === 126) {
common.skip('Skipping this test on AIX because blah blah something something.');
return;
}
assert.strictEqual(exitCode, 42); Not sure if there's an issue where that won't work in an exit handler, but I think it should. |
Its not a spec corner, its just a normal open of a file, and it works on AIX usually. Whatever is going on here smells more like a race condition. Or possibly a difference in allocation pattern of new descriptors, but it only fails sometimes.
|
I'm not saying you can't redirect stdout to /dev/null. I'm saying that it's not clear that you must be permitted to re-open the stdout fd on /dev/null after that fd has been explicitly closed. Or perhaps a bit more specifically, it's not clear that Interestingly, the open group man page for
(If I'm betraying profound ignorance and I should just stop already, you can say, "That's not how it works." and I'll stop. Just trying to be helpful.) |
I would be happier with marking the test as flaky until we figure out the right answer. |
Bear in mind it's generally completely deterministic on any given machine/environment in terms of which of the two results it gives, so marking it flaky on AIX (thus effectively ignoring the test) might be overkill and devalue its execution |
@Trott I'll talk about UNIX systems programming as long as you want, probably longer ;-). In the man pages you reference, previously and current mean the same thing, effectively. Previous means before The use-lowest available fd behaviour is ancient UNIX behaviour. A system that didn't do that would break the world, whether POSIX speced it or not (though it looks like they did from what you posted, or at least the opengroup did later, when they cleaned up the stuff POSIX argued about). |
@sam-github Yeah, it's all coming back to me now that this issue is more subtle than "AIX behaves differently". I mean, it does, but it's something subtle. Probably not going to discover the source of the issue by comparing man page texts. On the upside, this made me write a quick little C++ program to confirm my understanding and everything you're saying. Hooray for 10 more lines of C++ than I've written the entire rest of the year. |
@sxa555 I see your point, my one concern is that its easier to forget once the test has changed. Marked flaky in the status file it is obvious that something needs to be fixed. I'm willing to defer to the others on the thread if they want to chime in on which way is best. @sam-github the status file in the directory with the tests can be used to mark a test as either:
|
Refs: #8375 |
@sam-github @Trott if you 2 prefer landing with the option to accept either lets just do that. Can you comment here to confirm that. |
It looks like @jBarz has determined the problem point and that it appears to be a ksh bug (AIX-specific or otherwise). See #10234 (comment) If a workaround like I propose in #10234 (comment) is feasible, I think I'd prefer that to the change in this PR or skipping the test. The change I propose there has the benefit of still testing the C++ code that opens the fd on /dev/null, which is the point of the test. |
@Trott, If running under bash allows the test to pass reliably that sounds good to me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussion is ongoing in #10234, not approving to make sure no-one lands this by mistake.
This was superseded and addressed by #10339 |
Checklist
make -j4 test
(UNIX), orvcbuild test nosign
(Windows) passesAffected core subsystem(s)
test
Description of change
Fixes: #10234
Allow either of the two possible return codes on AIX to
be considered successful on test-stdio-closed.js. This is likely
an interim solution until we can be sure when AIX returns
one or the other, but I currently have systems that have both
and I don't want this failing on any of them.