-
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: document --abort-on-uncaught-exception #13931
src: document --abort-on-uncaught-exception #13931
Conversation
@misterdjules Is my doc text OK? If you can think of any improvements, I'm happy to make them. |
I think this should be backported down to and including 6.x @nodejs/lts (once it merges, of course) |
--> | ||
|
||
Aborting instead of exiting causes a core file to be generated for post-mortem | ||
analysis using a debugger (such as `lldb`, `gdb`, and `mdb`). |
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.
Isn't this dependent on system settings, e.g. ulimit -c
on Linux?
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.
By 'this' I mean the generation of a core file.
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, should I give some advice here on ulimit, or just say that it may generate a core file?
added: v0.10 | ||
--> | ||
|
||
Aborting instead of exiting causes a core file to be generated for post-mortem |
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.
Suggestion (feel free to take it or ignore it):
Abort the process and generate a core file if an uncaught exception occurs. The core file can be used for post-mortem analysis using a debugger such as lldb
, gdb
, and mdb
.
Just thinking out loud: My understanding of If it is still determined that it's worth it to handle and use the
|
@misterdjules You bring up good an interesting point, I had not noticed that, I brought it up in the async hooks PR. Personally, I think |
Some of the error (actually most) that happens in async_hooks we can't delegate to the @sam-github please just cc @nodejs/async_hooks if you have async_hooks questions. Commenting in the old thread is a little awkward. |
Thanks!
From a user experience perspective, I agree. However, if |
I think it would have to be based on perceived user-experience. Clearly putting 100s (literally) of ever-changing V8 options (they vary v8 release to release, and even vary by platform within a V8 release) would not be helpful. |
doc/api/cli.md
Outdated
added: v0.10 | ||
--> | ||
|
||
Abort (dump core) when an uncaught exception is thrown. On most systems this will |
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.
nit: it seems the rest of this file uses just one space after a dot at the start of a sentence.
Probably a question for LTS WG: Would documenting If not--if we might ship the V8 update anyway--then should a one-sentence disclaimer be added letting users know that its behavior could change and that won't be considered a breaking change the way it would for other flags? |
@Trott note that we document at least one other V8 option already, and that if V8 broke this behaviour in a way that Node couldn't fix itself, I would oppose shipping such a V8 update as a minor. The ability to core dump on uncaught exception is critical to post-mortem diagnostics, we can't rip that tool out of user's hands in a minor. And I don't think @ofrobots and team have any intention of changing this long-standing CLI option. |
@nodejs/post-mortem I am attempting to document a critical post-mortem debug tool, can I have some thumbs up, please? |
👍
👍 I think both these points should be documented " |
FWIW, I agree with what @sam-github said with the following:
|
Do we want to start implementing |
Yes, but that's true of any V8 API, and that's why we don't update V8 unless it's compatible.
Also agreed.
Given the above, I think we should specifically not say this, it should be considered a breaking change. |
doc/api/cli.md
Outdated
--> | ||
|
||
Abort (dump core) when an uncaught exception is thrown. On most systems this will | ||
generate a core file, though `ulimit -c unlimited` may be necessary if resource |
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.
[just asking] Are the clauses about ulimit
and on how to use core-dumps needed? Can't we assume (or link to) prior knowledge?
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 this is short enough that it's fine as-is here, linking to something that said these 10 words would be a bit overkill IMO.
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 added this from an earlier review comment. Many node users aren't familiar with ulimit and core dumps, and I'm pretty sure we've seen issues raised claiming the feature is broken because there is no core dump, this attempts to preempt that.
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.
its also hard to find good links, particularly to info that is generic across unixen. This has been a problem with man page links, too.
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.
Ack.
It was suggested to add the opposite claim — even though it's V8 we will consider it a breaking change |
Not sure that's needed, that's the semver default for any documented option. |
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.
LGTM
Generally when in doubt, I'd rather be explicit than implicit but I'm +0 on that. What's more important IMHO is making this an explicit feature support decision and documenting this internally, so it doesn't rot or regress. |
What triggered this PR is me trying to link to docs on
These are base O/S mechanisms, and we don't test them. It doesn't make sense to test that a core dump (written by the operating system!) can actually be read by a debugger, or test that an O/S really does implement POSIX process limits. |
It used to be implemented solely by V8, but has been a node option since
#12892. Its important for post-mortem
diagnostics and should be more prominently documented.
Checklist
Affected core subsystem(s)
src,doc