-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
src: honor --abort_on_uncaught_exception flag #2776
Conversation
Is it possible to add a test to prevent the regression from happening again? |
That was something I wasn't sure about. Would that require certain configurations on different systems? Or is there a particular exit code on an abort? |
I'm not sure, but it looks like the tests in 0af4c9e expect an exit code of 0. |
Aren't those explicitly catching the errors in the domain though? |
Ah, right. I'm just guessing here, but can you do anything like detect |
Yes, I believe I can actually. Will update shortly |
Ok, added a test that checks the signal in the error message of child_process.exec |
The CI doesn't seem to be happy with this. |
Yea, will look into today |
Ok, updated CI: https://ci.nodejs.org/job/node-test-pull-request/274/ Not sure whats up with the windows exit code?? Getting 3221226505... https://ci.nodejs.org/job/node-test-commit-windows/602/nodes=win2012r2/tapResults/ |
@evanlucas That's error code 0xC0000409 or STATUS_STACK_BUFFER_OVERRUN. |
@bnoordhuis is that what should occur when aborted on windows? |
I don't think so. The exit code on abort is normally 3. |
exec(cmd, function(err, stdout, stderr) { | ||
assert(err); | ||
// darwin only provides the signal on an abort | ||
// linux only provides the exit code (134) on an abort |
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.
This isn't right. Both platforms raise SIGABRT on abort()
but SIGABRT has a different signal number on Linux than on OS X, 6 vs. 22. When a process terminates after a signal, the exit code is 128 + signo
, so 134 on Linux and 150 on OS X.
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.
Sorry, I take that back - it's 6 on OS X as well, 22 is another platform. The point remains that both platforms should indicate that the process was killed by a signal.
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.
The CI croaked when I had it that way. On ubuntu, signal was null when abort occurred. On OS X, the exit code was null (at least when run as a child process) and the signal was provided
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 issue here is that you're using exec()
instead of spawn()
. The former runs the command through a shell and that may interfere with signal propagation.
ok, switched to spawn as that should fix the issues. New CI: https://ci.nodejs.org/job/node-test-pull-request/275/ |
Windows still having issues: https://ci.nodejs.org/job/node-test-commit-windows/605/nodes=win2012r2/tapTestReport/test.tap-1/
|
Yea, I saw that. I guess it makes sense that the signal on Windows should be null? |
Yes, libuv doesn't translate the exit code to a signal number. |
child.on('exit', function(code, sig) { | ||
if (!common.isWindows) { | ||
assert.strictEqual(sig, signal); | ||
} |
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.
SHould we still check something for windows? Otherwise, maybe produce skip output?
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 would think we should. I am just not sure what to check at this point on windows.
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.
If we are ignoring this assertion for windows, why don't we skip the test for windows?
if (flags) | ||
args.unshift(flags); | ||
|
||
var child = spawn(node, args); |
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.
const
:D
Ok, should be fixed now. CI: https://ci.nodejs.org/job/node-test-pull-request/294/ |
Looks like win2012 is still unhappy... |
LGTM if the CI is happy now |
raise(SIGABRT); | ||
#else | ||
abort(); | ||
#endif |
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.
Special-casing abort() here and only here is pretty meh IMO. At the very least add a comment but personally, I'd add an ABORT() macro to src/util.h and update all calls to abort() in src/ in one fell swoop.
LGTM |
Ok, updated with @bnoordhuis's suggestion. |
throw new Error('child error'); | ||
} else { | ||
run('', null); | ||
run('--abort-on-uncaught-exception', 'SIGABRT'); |
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.
@bnoordhuis will this generate core files that stick around every time tests run?
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.
if you have core dumps enabled, then it will
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.
That'll be a problem for a lot of devs, like myself. A test is nice, but allowing them to abort isn't so nice.
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 agree. Any suggestions on how to handle?
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.
Unfortunately no. I've had cases like this in the past as well, but never had a good solution. Possibly add it to another folder in test/
?
I moved the test to |
LGTM |
Windows 8+ compiled in Release mode exits with code 0xC0000409 when abort() is called. This prevents us from being able to reliably verify an abort exit code (3) on windows. PR-URL: nodejs#2776 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-by: Trevor Norris <trev.norris@gmail.com>
Fix regression introduced in 0af4c9e that ignores the --abort-on-uncaught-exception flag. Prior to that commit, the flag was passed through to v8. After that commit, the process just calls exit(1). PR-URL: nodejs#2776 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-by: Trevor Norris <trev.norris@gmail.com>
Would it not be better to use an inline function with a unique name like |
@skomski could you be more specific on what is making this macro unsafe? It is also implemented similarly to the other macros in src/util.h |
@evanlucas I would always prefer a inline function over a macro if its possible and the name It's simply unnecessary to use a macro in this case. |
Windows 8+ compiled in Release mode exits with code 0xC0000409 when abort() is called. This prevents us from being able to reliably verify an abort exit code (3) on windows. PR-URL: #2776 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-by: Trevor Norris <trev.norris@gmail.com>
Fix regression introduced in 0af4c9e that ignores the --abort-on-uncaught-exception flag. Prior to that commit, the flag was passed through to v8. After that commit, the process just calls exit(1). PR-URL: #2776 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-by: Trevor Norris <trev.norris@gmail.com>
I've added land-on-v3.x and land-on-v4.x labels. Remove them if that's wrong but please remove them from #3058 as well. |
Fix regression introduced in 0af4c9e
that ignores the --abort-on-uncaught-exception flag. Prior to that
commit, the flag was passed through to v8. After that commit, the
process just calls exit(1).
The tests added in 0af4c9e all are still passing.
There probably is a better way of doing this, but this is working for me, so...