doc: note that listening on SIGSEGV & co is unsafe #8410
Conversation
Note that trying to listen for some signals using `process.on()` is unsafe in the `process` docs.
addaleax
added
doc
Listening for one of these signals from JS will make the process enter an infinite loop when encountering them naturally because the underlying problem is not resolved while the signal handler is being scheduled. Ref: npm/npm#13782 Ref: nodejs/node#8410
|
LGTM |
| @@ -422,6 +422,9 @@ It is important to take note of the following: | |||
| * `SIGKILL` cannot have a listener installed, it will unconditionally terminate | |||
| Node.js on all platforms. | |||
| * `SIGSTOP` cannot have a listener installed. | |||
| * `SIGBUS`, `SIGFPE`, `SIGSEGV` and `SIGILL`, when not raised artificially, | |||
| inherently leave the process in a state from which it is not safe to | |||
| attempt to call JS listeners. | |||
There was a problem hiding this comment.
Does core not call listeners then...?
There was a problem hiding this comment.
libuv schedules them to run, but the control flow returns from the signal handler before actually calling anything. As far as I have been able to tell, that means that the offending code will just be executed again, triggering the signal again, etc. in an infinite loop.
There was a problem hiding this comment.
@Fishrock123 sorry, occurs to me that I might have misread your question – node does try to call the listeners in the usual way, and that works perfectly when the signal is artificially generated, as in process.kill(process.pid, 'SIGSEGV').
There was a problem hiding this comment.
and that works perfectly when the signal is artificially generated,
Does that imply that we should not allow these signals to trigger when they are not artificial?
There was a problem hiding this comment.
Does that imply that we should not allow these signals to trigger when they are not artificial?
We might be able to do that… libuv would need to set SA_SIGINFO, which comes with this warning in the Linux manpage:
Use of these latter values in sa_flags may be less portable in applications intended for older UNIX implementations.
I am not sure what practical use cases for manually triggering SIGSEGV there are, though.
There was a problem hiding this comment.
@addaleax I mean, should these listeners even function if it is not safe?
There was a problem hiding this comment.
@Fishrock123 I would say no, but it’s probably not something worth the trouble of removing…
|
LGTM |
| @@ -422,6 +422,9 @@ It is important to take note of the following: | |||
| * `SIGKILL` cannot have a listener installed, it will unconditionally terminate | |||
| Node.js on all platforms. | |||
| * `SIGSTOP` cannot have a listener installed. | |||
| * `SIGBUS`, `SIGFPE`, `SIGSEGV` and `SIGILL`, when not raised artificially, | |||
There was a problem hiding this comment.
raised artificially is a bit obscure. I'm not sure the average reader will know that that means.
|
While this is ok in general, I think it would be beneficial to describe the risk a bit more. |
|
It seems fine to me as is, really. You could s/raised artificially/sent explicitly/ but that's not even much of an improvement, IMO. |
|
I’ve added a bit more explanation on what might happen and a reference to the |
Listening for one of these signals from JS will make the process enter an infinite loop when encountering them naturally because the underlying problem is not resolved while the signal handler is being scheduled. Ref: npm/npm#13782 Ref: nodejs/node#8410
|
seems fine to me then |
|
LGTM. I appreciate the tweaks. |
|
LGTM |
Note that trying to listen for some signals using `process.on()` is unsafe in the `process` docs. PR-URL: #8410 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
|
Landed in 3207ea4 |
Note that trying to listen for some signals using `process.on()` is unsafe in the `process` docs. PR-URL: #8410 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Checklist
Affected core subsystem(s)
doc
Description of change
Note that trying to listen for some signals using
process.on()is unsafe in theprocessdocs.