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

src: honor --abort_on_uncaught_exception flag #2776

Merged
merged 2 commits into from
Sep 17, 2015

Conversation

evanlucas
Copy link
Contributor

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...

@mscdex mscdex added the c++ Issues and PRs that require attention from people who are familiar with C++. label Sep 9, 2015
@cjihrig
Copy link
Contributor

cjihrig commented Sep 9, 2015

Is it possible to add a test to prevent the regression from happening again?

@evanlucas
Copy link
Contributor Author

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?

@cjihrig
Copy link
Contributor

cjihrig commented Sep 9, 2015

I'm not sure, but it looks like the tests in 0af4c9e expect an exit code of 0.

@evanlucas
Copy link
Contributor Author

Aren't those explicitly catching the errors in the domain though?

@cjihrig
Copy link
Contributor

cjihrig commented Sep 9, 2015

Ah, right. I'm just guessing here, but can you do anything like detect SIGABRT or check the process output.

@evanlucas
Copy link
Contributor Author

Yes, I believe I can actually. Will update shortly

@evanlucas
Copy link
Contributor Author

Ok, added a test that checks the signal in the error message of child_process.exec

@evanlucas
Copy link
Contributor Author

@cjihrig
Copy link
Contributor

cjihrig commented Sep 10, 2015

The CI doesn't seem to be happy with this.

@evanlucas
Copy link
Contributor Author

Yea, will look into today

@evanlucas
Copy link
Contributor Author

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/

@bnoordhuis
Copy link
Member

@evanlucas That's error code 0xC0000409 or STATUS_STACK_BUFFER_OVERRUN.

@evanlucas
Copy link
Contributor Author

@bnoordhuis is that what should occur when aborted on windows?

@bnoordhuis
Copy link
Member

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
Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

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.

@evanlucas
Copy link
Contributor Author

ok, switched to spawn as that should fix the issues. New CI: https://ci.nodejs.org/job/node-test-pull-request/275/

@Fishrock123
Copy link
Contributor

Windows still having issues:

https://ci.nodejs.org/job/node-test-commit-windows/605/nodes=win2012r2/tapTestReport/test.tap-1/

# 
# assert.js:89
# throw new assert.AssertionError({
# ^
# AssertionError: null === 'SIGABRT'

@evanlucas
Copy link
Contributor Author

Yea, I saw that. I guess it makes sense that the signal on Windows should be null?

@bnoordhuis
Copy link
Member

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);
}
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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?

@Fishrock123 Fishrock123 mentioned this pull request Sep 13, 2015
7 tasks
if (flags)
args.unshift(flags);

var child = spawn(node, args);
Copy link
Contributor

Choose a reason for hiding this comment

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

const :D

@evanlucas
Copy link
Contributor Author

Ok, should be fixed now. CI: https://ci.nodejs.org/job/node-test-pull-request/294/

@evanlucas
Copy link
Contributor Author

Looks like win2012 is still unhappy...

@cjihrig
Copy link
Contributor

cjihrig commented Sep 16, 2015

LGTM if the CI is happy now

raise(SIGABRT);
#else
abort();
#endif
Copy link
Member

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.

@mscdex
Copy link
Contributor

mscdex commented Sep 16, 2015

LGTM

@evanlucas
Copy link
Contributor Author

Ok, updated with @bnoordhuis's suggestion.

@evanlucas
Copy link
Contributor Author

throw new Error('child error');
} else {
run('', null);
run('--abort-on-uncaught-exception', 'SIGABRT');
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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/?

@evanlucas
Copy link
Contributor Author

I moved the test to test/abort per @trevnorris. PTAL

@trevnorris
Copy link
Contributor

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>
@skomski
Copy link
Contributor

skomski commented Sep 17, 2015

Would it not be better to use an inline function with a unique name like NodeAbort rather than an unsafe macro with a name where it's not clear if it's defined by node?

@evanlucas
Copy link
Contributor Author

@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

@skomski
Copy link
Contributor

skomski commented Sep 17, 2015

@evanlucas I would always prefer a inline function over a macro if its possible and the name ABORT is not unique which makes it even more unsafe and unclear who provides it. It's not a special case like CHECK.
More from style guide: https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Preprocessor_Macros.

It's simply unnecessary to use a macro in this case.

evanlucas added a commit that referenced this pull request Sep 20, 2015
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>
evanlucas added a commit that referenced this pull request Sep 20, 2015
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>
@rvagg rvagg mentioned this pull request Sep 22, 2015
@bnoordhuis
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++.
Projects
None yet
Development

Successfully merging this pull request may close these issues.