Skip to content

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
@addaleaxaddaleax 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-botnodejs-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
MemberAuthor

Copy link
Contributor

@apapirovskiapapirovski 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
MemberAuthor

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
Contributor

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
MemberAuthor

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

@addaleaxaddaleax 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
MemberAuthor

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 :)

@addaleaxaddaleax removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Nov 27, 2017
@addaleaxaddaleax added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Nov 27, 2017

NO_RETURN voidFatalError(constchar* location, constchar* 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

@AndreasMadsenAndreasMadsen 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
MemberAuthor

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> voidUSE(T&&){}

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

Copy link
MemberAuthor

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


NO_RETURN voidFatalError(constchar* location, constchar* 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

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


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
MemberAuthor

Choose a reason for hiding this comment

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

Yup, done.

@addaleaxaddaleax 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
MemberAuthor

Landed in a012672, 04e3aa2

@addaleaxaddaleax 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 <[email protected]> Reviewed-By: Timothy Gu <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Andreas Madsen <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
addaleax added a commit that referenced this pull request Nov 29, 2017
PR-URL: #17333 Reviewed-By: Timothy Gu <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
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 <[email protected]> Reviewed-By: Timothy Gu <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Andreas Madsen <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
MylesBorins pushed a commit that referenced this pull request Dec 12, 2017
PR-URL: #17333 Reviewed-By: Timothy Gu <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
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 <[email protected]> Reviewed-By: Timothy Gu <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Andreas Madsen <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
MylesBorins pushed a commit that referenced this pull request Dec 12, 2017
PR-URL: #17333 Reviewed-By: Timothy Gu <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
@MylesBorinsMylesBorins mentioned this pull request Dec 12, 2017
Sign up for freeto 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 / srcIssues 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

@addaleax@apapirovski@bnoordhuis@danbev@jasnell@AndreasMadsen@TimothyGu@cjihrig@nodejs-github-bot