-
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: adds report_on_fatalerror option to per_process #29881
src: adds report_on_fatalerror option to per_process #29881
Conversation
@@ -231,6 +231,7 @@ class PerProcessOptions : public Options { | |||
|
|||
#ifdef NODE_REPORT | |||
std::vector<std::string> cmdline; | |||
bool report_on_fatalerror = false; |
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.
Can you also remove the report_on_fatalerror
option from the per-Isolate option list?
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.
Is there any other case where we might need it? I left it as I was not clear on that.
@addaleax / @gireeshpunathil
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.
@shobhitchittora I’m not sure what you mean by that – you’ve moved the option to a wider scope, so the original field is now useless and can be removed.
(You do need to update the references in node_report_module.cc
as well in order for that to work.)
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.
Okay! Got it.
@addaleax Just a doubt here. Do the spawned child processes also share the same set of per process flags? |
Not necessarily – it depends on whether the child shares its parent’s
I think it’s fine to leave that where it is for now – ultimately, it doesn’t matter much, because the experimental flag is going to go away eventually anyway. |
@@ -63,6 +63,15 @@ void PerProcessOptions::CheckOptions(std::vector<std::string>* errors) { | |||
"used, not both"); | |||
} | |||
#endif | |||
|
|||
// #ifdef NODE_REPORT |
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.
Do I need to move this check in per-process option checks? Do we still need a dependency on --experimental-report
flag being set.
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.
yes, I'd say so.
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.
Do we still need a dependency on
--experimental-report
flag being set.
I think that gets a bit tricky here, so I’m fine with omitting it.
const report = reports[0]; | ||
helper.validate(report); | ||
|
||
args = ['--max-old-space-size=20', |
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.
FYI, just using --report-on-fatalerror
flag here would generate a report on fatal error without relying on --experimental-report
flag.
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 wouldn't expect a report on fatal if the --experimental-report
flag was not present
ping @shobhitchittora . Also I think this needs to be reconciled / ratified between @addaleax and @boneskull ? i.e. : If |
Hi all! |
I think @addaleax should see my review comments above |
AddOption("--report-on-fatalerror", | ||
"generate diagnostic report on fatal (internal) errors", | ||
&PerProcessOptions::report_on_fatalerror, | ||
kAllowedInEnvironment); |
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 is mis-indented (it’s inside a function so it should not be right at the start of the line)
@@ -119,13 +119,13 @@ static void SetSignal(const FunctionCallbackInfo<Value>& info) { | |||
static void ShouldReportOnFatalError(const FunctionCallbackInfo<Value>& info) { | |||
Environment* env = Environment::GetCurrent(info); | |||
info.GetReturnValue().Set( | |||
env->isolate_data()->options()->report_on_fatalerror); | |||
node::per_process::cli_options->report_on_fatalerror); |
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 you should acquire node::per_process::cli_options_mutex
in this case, to avoid race conditions when accessing this from multiple threads.
Also, it’s not important, but the previous indentation was the standard one we use for statement continuations (4 spaces).
@@ -63,6 +63,15 @@ void PerProcessOptions::CheckOptions(std::vector<std::string>* errors) { | |||
"used, not both"); | |||
} | |||
#endif | |||
|
|||
// #ifdef NODE_REPORT |
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.
Do we still need a dependency on
--experimental-report
flag being set.
I think that gets a bit tricky here, so I’m fine with omitting it.
Ping @shobhitchittora. This needs a rebase and there are a few small comments left. |
moving the flag to per_process allows to read it's value on fatal error where env is null Fixes: nodejs#29601
8845fa4
to
decb848
Compare
@shobhitchittora - with this change, I am getting a report if I run a program like this: |
[ trying to see if we can accommodate this in the upcoming release ] @shobhitchittora - according to #29881 (comment) , looks like this still has minor work to do. are you planning to progress on this? Also please let me know if you need any help with the missing piece. If you are not in a position to progress, no issues, pls let me know! |
@gireeshpunathil I don't think I'd be able to pick this up, due to my busy schedule. Thanks for your patience. Feel free to pick up the commits for your usage. |
thanks @shobhitchittora for the quick response! |
--report-on-fatalerror was not honored properly, as there was no way to check the value which was stored in the Environment pointer which can be inaccessible under certain fatal error situations. Move the flag out of Environment pointer so that this is doable. Co-authored-by: Shobhit Chittora schittora@paypal.com Fixes: nodejs#31576 Refs: nodejs#29881
--report-on-fatalerror was not honored properly, as there was no way to check the value which was stored in the Environment pointer which can be inaccessible under certain fatal error situations. Move the flag out of Environment pointer so that this is doable. Co-authored-by: Shobhit Chittora schittora@paypal.com PR-URL: #32207 Fixes: #31576 Refs: #29881 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
--report-on-fatalerror was not honored properly, as there was no way to check the value which was stored in the Environment pointer which can be inaccessible under certain fatal error situations. Move the flag out of Environment pointer so that this is doable. Co-authored-by: Shobhit Chittora schittora@paypal.com PR-URL: #32207 Fixes: #31576 Refs: #29881 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
It seems like this can be closed, given that #32207 landed. Please reopen if that is incorrect. Thanks for the PR. |
--report-on-fatalerror was not honored properly, as there was no way to check the value which was stored in the Environment pointer which can be inaccessible under certain fatal error situations. Move the flag out of Environment pointer so that this is doable. Co-authored-by: Shobhit Chittora schittora@paypal.com PR-URL: nodejs#32207 Fixes: nodejs#31576 Refs: nodejs#29881 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
--report-on-fatalerror was not honored properly, as there was no way to check the value which was stored in the Environment pointer which can be inaccessible under certain fatal error situations. Move the flag out of Environment pointer so that this is doable. Co-authored-by: Shobhit Chittora schittora@paypal.com PR-URL: #32207 Fixes: #31576 Refs: #29881 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Description
moving the
report_on_fatalerror
flag toper_process
as it allows to read it's value on fatal error whereenv
itself is null.Fixes: #29601
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes