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: adds report_on_fatalerror option to per_process #29881

Conversation

shobhitchittora
Copy link
Contributor

@shobhitchittora shobhitchittora commented Oct 7, 2019

Description

moving the report_on_fatalerror flag to per_process as it allows to read it's value on fatal error where env itself is null.

Fixes: #29601

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added the c++ Issues and PRs that require attention from people who are familiar with C++. label Oct 7, 2019
@@ -231,6 +231,7 @@ class PerProcessOptions : public Options {

#ifdef NODE_REPORT
std::vector<std::string> cmdline;
bool report_on_fatalerror = false;
Copy link
Member

@addaleax addaleax Oct 7, 2019

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?

Copy link
Contributor Author

@shobhitchittora shobhitchittora Oct 7, 2019

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

Copy link
Member

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay! Got it.

@shobhitchittora
Copy link
Contributor Author

shobhitchittora commented Oct 8, 2019

@addaleax Just a doubt here. Do the spawned child processes also share the same set of per process flags?
Also since --report-on-fatalerror is dependent on --experimental-report, should it also be moved to the per process level?

@addaleax
Copy link
Member

addaleax commented Oct 8, 2019

@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 NODE_OPTIONS environment variable and whether child_process.fork() was used. I don’t think that’s a concern here, though.

Also since --report-on-fatalerror is dependent on --experimental-report, should it also be moved to the per process level?

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
Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Member

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',
Copy link
Contributor Author

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.

Copy link
Contributor

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

@gireeshpunathil
Copy link
Member

ping @shobhitchittora .

Also I think this needs to be reconciled / ratified between @addaleax and @boneskull ? i.e. : If --experimental-report is left under per-environment, we still get into a situation where we cannot check its presence on a fatalerror?

@shobhitchittora
Copy link
Contributor Author

Hi all!
Sorry for late reply here. I was traveling for some time and just came back.
@addaleax / @boneskull would like your input on what @gireeshpunathil has mentioned, to move ahead.

@boneskull
Copy link
Contributor

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

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

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.

@BridgeAR
Copy link
Member

Ping @shobhitchittora. This needs a rebase and there are a few small comments left.

Shobhit Chittora added 2 commits January 12, 2020 10:58
moving the flag to per_process allows to read it's value
on fatal error where env is null

Fixes: nodejs#29601
@shobhitchittora shobhitchittora force-pushed the fatal-error-diagnostic-report branch from 8845fa4 to decb848 Compare January 12, 2020 05:30
@richardlau richardlau added the report Issues and PRs related to process.report. label Jan 30, 2020
@HarshithaKP
Copy link
Member

@shobhitchittora - with this change, I am getting a report if I run a program like this: node --max-old-space-size=5 --report-on-fatalerror foo.js - that is, no --experimental-report flag is ON. I believe this is not expected? Pls let me know.

@gireeshpunathil
Copy link
Member

[ 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!

@shobhitchittora
Copy link
Contributor Author

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

@gireeshpunathil
Copy link
Member

thanks @shobhitchittora for the quick response!

HarshithaKP added a commit to HarshithaKP/node that referenced this pull request Mar 24, 2020
--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
sam-github pushed a commit that referenced this pull request Mar 25, 2020
--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>
MylesBorins pushed a commit that referenced this pull request Mar 25, 2020
--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>
@cjihrig
Copy link
Contributor

cjihrig commented Mar 26, 2020

It seems like this can be closed, given that #32207 landed. Please reopen if that is incorrect. Thanks for the PR.

@cjihrig cjihrig closed this Mar 26, 2020
targos pushed a commit to targos/node that referenced this pull request Apr 25, 2020
--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>
targos pushed a commit that referenced this pull request Apr 28, 2020
--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>
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++. report Issues and PRs related to process.report.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants