Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.4k
test: fix test-debug-port-numbers on OS X#7046
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
Conversation
santigimeno commented May 29, 2016 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
santigimeno commented May 29, 2016
This test was failing in |
santigimeno commented May 29, 2016
Stress test without this change fails: https://ci.nodejs.org/job/node-stress-single-test/749. |
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.
I think the logic should be ESRCH || EPERM iff OS X, and you might as well drop the 'iff OS X' part in that case because the BSDs probably exhibit the same behavior.
I checked the xnu and libc sources and the error code seems to depend on whether POSIX compatibility mode is enabled in the libc wrapper: it returns EPERM if it is, ESRCH otherwise. That would explain why I don't see EPERM with 10.8.
cjihrig commented May 29, 2016
LGTM. I think @bnoordhuis suggestion makes sense. One question though:
Does that mean that processes may be left behind? |
bnoordhuis commented May 29, 2016
@cjihrig My reading of the xnu sources is that EPERM or ESRCH are only returned when the process group is gone (i.e., empty.) |
santigimeno commented May 29, 2016
@bnoordhuis, from the |
bnoordhuis commented May 29, 2016
I think xnu inherits most of its signal handling logic from FreeBSD but it's possible that the POSIX compatibility stuff is a later addition. I don't think allowing EPERM on other platforms will hurt, at any rate. |
santigimeno commented May 29, 2016
Yes, it makes sense. So just to be sure... |
bnoordhuis commented May 29, 2016
I'd do it unconditionally, i.e., no platform-specific checks. |
santigimeno commented May 29, 2016
PR updated per your comments. Thanks! |
santigimeno commented May 29, 2016
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.
I don't think this is right. 'EPERM' || 'ESRCH' will always evaluate to EPERM
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.
Also, assert.ok() just asserts that e.code is truthy.
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.
You're right. I was fixing that :(
santigimeno commented May 29, 2016
Updated |
cjihrig commented May 29, 2016
LGTM |
santigimeno commented May 29, 2016
bnoordhuis commented May 29, 2016
LGTM |
According to kill(2), kill returns `EPERM` error if when signalling a process group any of the members could not be signalled. PR-URL: nodejs#7046 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
santigimeno commented May 30, 2016
CI: https://ci.nodejs.org/job/node-test-commit/3579/. All green except some unrelated failures in some ARM bots. Landing |
santigimeno commented May 30, 2016
Landed in 6e148a3. Thanks! |
According to kill(2), kill returns `EPERM` error if when signalling a process group any of the members could not be signalled. PR-URL: nodejs#7046 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
According to kill(2), kill returns `EPERM` error if when signalling a process group any of the members could not be signalled. PR-URL: #7046 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
According to kill(2), kill returns `EPERM` error if when signalling a process group any of the members could not be signalled. PR-URL: #7046 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
According to kill(2), kill returns `EPERM` error if when signalling a process group any of the members could not be signalled. PR-URL: #7046 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
According to kill(2), kill returns `EPERM` error if when signalling a process group any of the members could not be signalled. PR-URL: #7046 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
According to kill(2), kill returns `EPERM` error if when signalling a process group any of the members could not be signalled. PR-URL: #7046 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
According to kill(2), kill returns `EPERM` error if when signalling a process group any of the members could not be signalled. PR-URL: #7046 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
Checklist
Affected core subsystem(s)
test
Description of change
According to kill(2), kill returns
EPERMerror if when signalling aprocess group any of the members could not be signaled.
Refs: #7037