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: remove ClearFatalExceptionHandlers() #17333

Closed

Conversation

addaleax
Copy link
Member

At its call sites, ClearFatalExceptionHandlers() was used to
make the process crash as soon as possible once an exception occurred,
without giving JS land a chance to interfere.

ClearFatalExceptionHandlers() awkwardly removed the current domain
and any uncaughtException handlers, whereas a clearer way is to
execute the relevant reporting (and exit()) code directly.

Refs: #17159
Refs: #17324

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

src

At its call sites, `ClearFatalExceptionHandlers()` was used to
make the process crash as soon as possible once an exception occurred,
without giving JS land a chance to interfere.

`ClearFatalExceptionHandlers()` awkwardly removed the current domain
and any `uncaughtException` handlers, whereas a clearer way is to
execute the relevant reporting (and `exit()`) code directly.

Refs: nodejs#17159
Refs: nodejs#17324
@addaleax addaleax added c++ Issues and PRs that require attention from people who are familiar with C++. dont-land-on-v6.x lib / src Issues and PRs related to general changes in the lib or src directory. labels Nov 27, 2017
@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. labels Nov 27, 2017
@addaleax
Copy link
Member Author

Copy link
Member

@apapirovski apapirovski left a comment

Choose a reason for hiding this comment

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

This is a very clean way of doing this. Nice 👍 🥇

One question: would this still emit an exit event on the process?

@addaleax
Copy link
Member Author

One question: would this still emit an exit event on the process?

Hm; I think the answer is “no, and that is what we want, even if it happened before” – all of these sound like they should be hard crashes due to Node being in an invalid state?

@apapirovski
Copy link
Member

Hm; I think the answer is “no, and that is what we want, even if it happened before” – all of these sound like they should be hard crashes due to Node being in an invalid state?

Yea, that's fine but I just want to flag the difference in case there's any reason we would care about it. I don't know if anyone could really be relying on that event in this particular situation.

@addaleax
Copy link
Member Author

@apapirovski I’m glad you pointed it out. :)

@addaleax addaleax added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Nov 27, 2017
}
FatalTryCatch try_catch(env);
fn->Call(env->context(), Undefined(env->isolate()), 1, &async_id_value)
.ToLocalChecked();
Copy link
Member

Choose a reason for hiding this comment

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

Should ToLocalChecked() be used here? It would make the program hard-crash before the FatalTryCatch got time to terminate the program with error message... right?

Copy link
Member Author

Choose a reason for hiding this comment

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

@TimothyGu Yeah, you’re right. Updated :)

@addaleax addaleax removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Nov 27, 2017
@addaleax addaleax added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Nov 27, 2017
@@ -277,6 +277,17 @@ void AppendExceptionLine(Environment* env,

NO_RETURN void FatalError(const char* location, const char* message);

// Like a `TryCatch` but it crashes the process if it did catch an exception.
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: Perhaps this could rephrased to something like "Like a TryCatch but crashes the process if an exception was caught"?

Copy link
Member

Choose a reason for hiding this comment

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

I'd also write "exits" instead of "crashes" because the latter suggests segfaults and aborts (in my mind at least.)

Copy link
Member

@AndreasMadsen AndreasMadsen left a comment

Choose a reason for hiding this comment

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

LGTM

This is really nice, good job :)

UNREACHABLE();
}
FatalTryCatch try_catch(env);
(void)fn->Call(env->context(), Undefined(env->isolate()), 1, &async_id_value);
Copy link
Member

Choose a reason for hiding this comment

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

The (void)... is to suppress the -Wunused-result warning? That works with clang but gcc still emits a warning, AFAIK.

Copy link
Member Author

Choose a reason for hiding this comment

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

@bnoordhuis It appears this depends on the gcc version: gcc 6 doesn’t complain, gcc 7 does? I think older versions of it were also fine with it…

I’ve went with a dummy .FromMaybe call, that doesn’t seem quite as pretty but I’m not sure what a better way would be

Copy link
Member

Choose a reason for hiding this comment

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

It used to be a long-standing gcc bug that was only partially fixed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509 from 2005.

I suppose now might be a good a time as any to introduce a Use() or USE() function:

template <typename T> void USE(T&&) {}

Good idea, bad idea? If bad idea, I'm fine with (void)....

Copy link
Member Author

Choose a reason for hiding this comment

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

It’s a good idea, I’ve added a new commit with that (both for the code bits here and those where we use (void).

@@ -277,6 +277,17 @@ void AppendExceptionLine(Environment* env,

NO_RETURN void FatalError(const char* location, const char* message);

// Like a `TryCatch` but it crashes the process if it did catch an exception.
Copy link
Member

Choose a reason for hiding this comment

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

I'd also write "exits" instead of "crashes" because the latter suggests segfaults and aborts (in my mind at least.)

Copy link
Member

@TimothyGu TimothyGu left a comment

Choose a reason for hiding this comment

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

Still LGTM.

@@ -5358,7 +5358,7 @@ void ECDH::SetPrivateKey(const FunctionCallbackInfo<Value>& args) {
EC_KEY_set_public_key(ecdh->key_, nullptr);

MarkPopErrorOnReturn mark_pop_error_on_return;
(void) &mark_pop_error_on_return; // Silence compiler warning.
USE(&mark_pop_error_on_return); // Silence compiler warning.
Copy link
Member

Choose a reason for hiding this comment

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

You could move this comment to where USE() is defined.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yup, done.

@addaleax addaleax removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Nov 29, 2017
@addaleax
Copy link
Member Author

Landed in a012672, 04e3aa2

@addaleax addaleax closed this Nov 29, 2017
@addaleax addaleax deleted the no-clear-fatal-exception-handlers branch November 29, 2017 15:02
addaleax added a commit that referenced this pull request Nov 29, 2017
At its call sites, `ClearFatalExceptionHandlers()` was used to
make the process crash as soon as possible once an exception occurred,
without giving JS land a chance to interfere.

`ClearFatalExceptionHandlers()` awkwardly removed the current domain
and any `uncaughtException` handlers, whereas a clearer way is to
execute the relevant reporting (and `exit()`) code directly.

PR-URL: #17333
Refs: #17159
Refs: #17324
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
addaleax added a commit that referenced this pull request Nov 29, 2017
PR-URL: #17333
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
MylesBorins pushed a commit that referenced this pull request Dec 12, 2017
At its call sites, `ClearFatalExceptionHandlers()` was used to
make the process crash as soon as possible once an exception occurred,
without giving JS land a chance to interfere.

`ClearFatalExceptionHandlers()` awkwardly removed the current domain
and any `uncaughtException` handlers, whereas a clearer way is to
execute the relevant reporting (and `exit()`) code directly.

PR-URL: #17333
Refs: #17159
Refs: #17324
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
MylesBorins pushed a commit that referenced this pull request Dec 12, 2017
PR-URL: #17333
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
MylesBorins pushed a commit that referenced this pull request Dec 12, 2017
At its call sites, `ClearFatalExceptionHandlers()` was used to
make the process crash as soon as possible once an exception occurred,
without giving JS land a chance to interfere.

`ClearFatalExceptionHandlers()` awkwardly removed the current domain
and any `uncaughtException` handlers, whereas a clearer way is to
execute the relevant reporting (and `exit()`) code directly.

PR-URL: #17333
Refs: #17159
Refs: #17324
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
MylesBorins pushed a commit that referenced this pull request Dec 12, 2017
PR-URL: #17333
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Dec 12, 2017
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++. lib / src Issues and PRs related to general changes in the lib or src directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants