-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
v8: fix process.abort() interaction with V8 #13985
Conversation
Maybe also remove the |
See v8/v8@3f45368, it was made configurable upstream. We should probably just cherry-pick that patch. API/ABI stability is not a concern because libplatform and |
Original commit message: d8: Make in process stack dumping optional Adds a flag (--disable-in-process-stack-traces) to not install signal handlers so that e.g. ASan signal handlers will work. This flag mirrors chromium's one. R=jochen@chromium.org BUG=chromium:716235 Review-Url: https://codereview.chromium.org/2854173002 Cr-Commit-Position: refs/heads/master@{nodejs#45142} PR-URL: nodejs#13985
e8f4977
to
6f5a794
Compare
@bnoordhuis Thanks for the pointer; I’ve updated this. |
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 with a comment.
test/parallel/test-abort-exitcode.js
Outdated
assert.strictEqual(signal, 'SIGABRT'); | ||
} | ||
})); | ||
} |
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 should probably go into test/abort. I'm kind of surprised to discover that the test from #12914 went into test/parallel, that seems wrong. (edit: oh wait, that test only runs on Windows.)
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 for context: because of the core dumps taking up storage?
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.
Correct.
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.
Same goes for async_hooks/test-callback-error.js
. But it is problematic that we don't have any abort tests running on CI, it is only because we put async_hooks/test-callback-error.js
in the wrong directory that we discovered this bug.
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’ve moved the 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.
But it is problematic that we don't have any abort tests running on CI, it is only because we put async_hooks/test-callback-error.js in the wrong directory that we discovered this bug.
I wonder if @nodejs/build can set up a single machine that is suitable to run those tests. Not sure what is required: That it be configured to not write core dumps? Or that it have a large enough disk to write core dumps and has a clean up task to delete them when the tests are done?
Anyway, if it's possible, maybe CI runs can at least run the tests in abort
on a single platform, which is better than not running them at all ever. And it might make a good prototype for also running pummel
and maybe even internet
tests...
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.
That it be configured to not write core dumps?
That would be the easiest, I guess. I don’t see why we wouldn’t be able to just do that in the test runner:
import resource
resource.setrlimit(resource.RLIMIT_CORE, (0,0))
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 wonder if @nodejs/build can set up a single machine that is suitable to run those tests.
IMHO it won't be enough... there have been at least 3 abort
related fixes in the last couple of weeks, on three different platforms...
An alternative might be a programmatic way to delete the core-dumps from within the test a la common.refreshTmpDir()
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.
Since V8 5.9 V8 installs a default signal handler for some signals when creating a default platform instance that prints a stack trace. However, Node already does the same thing, so it would seem like the two different stack traces would be printed; also, the V8 handler would lead to a `SIGSEGV` under some circumstances, rather than letting the abort continue normally. Resolve this by disabling V8’s signal handler by default. Fixes: nodejs#13865
6f5a794
to
9ca4062
Compare
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.
Largely rubber stamp LGTM
This fixes |
A @refack-inspired post-land CI run: https://ci.nodejs.org/job/node-test-commit/10894/ |
YAY for the land! With npm-install of PI3 back to passing, we might have a green CI 💃 |
I think #14029 still has to land before we get to green. |
Original commit message: d8: Make in process stack dumping optional Adds a flag (--disable-in-process-stack-traces) to not install signal handlers so that e.g. ASan signal handlers will work. This flag mirrors chromium's one. R=jochen@chromium.org BUG=chromium:716235 Review-Url: https://codereview.chromium.org/2854173002 Cr-Commit-Position: refs/heads/master@{nodejs#45142} PR-URL: nodejs#13985 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Since V8 5.9 V8 installs a default signal handler for some signals when creating a default platform instance that prints a stack trace. However, Node already does the same thing, so it would seem like the two different stack traces would be printed; also, the V8 handler would lead to a `SIGSEGV` under some circumstances, rather than letting the abort continue normally. Resolve this by disabling V8’s signal handler by default. PR-URL: nodejs#13985 Fixes: nodejs#13865 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message: d8: Make in process stack dumping optional Adds a flag (--disable-in-process-stack-traces) to not install signal handlers so that e.g. ASan signal handlers will work. This flag mirrors chromium's one. R=jochen@chromium.org BUG=chromium:716235 Review-Url: https://codereview.chromium.org/2854173002 Cr-Commit-Position: refs/heads/master@{#45142} PR-URL: #13985 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Since V8 5.9 V8 installs a default signal handler for some signals when creating a default platform instance that prints a stack trace. However, Node already does the same thing, so it would seem like the two different stack traces would be printed; also, the V8 handler would lead to a `SIGSEGV` under some circumstances, rather than letting the abort continue normally. Resolve this by disabling V8’s signal handler by default. PR-URL: #13985 Fixes: #13865 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message: d8: Make in process stack dumping optional Adds a flag (--disable-in-process-stack-traces) to not install signal handlers so that e.g. ASan signal handlers will work. This flag mirrors chromium's one. R=jochen@chromium.org BUG=chromium:716235 Review-Url: https://codereview.chromium.org/2854173002 Cr-Commit-Position: refs/heads/master@{#45142} PR-URL: #13985 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Since V8 5.9 V8 installs a default signal handler for some signals when creating a default platform instance that prints a stack trace. However, Node already does the same thing, so it would seem like the two different stack traces would be printed; also, the V8 handler would lead to a `SIGSEGV` under some circumstances, rather than letting the abort continue normally. Resolve this by disabling V8’s signal handler by default. PR-URL: #13985 Fixes: #13865 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message: d8: Make in process stack dumping optional Adds a flag (--disable-in-process-stack-traces) to not install signal handlers so that e.g. ASan signal handlers will work. This flag mirrors chromium's one. R=jochen@chromium.org BUG=chromium:716235 Review-Url: https://codereview.chromium.org/2854173002 Cr-Commit-Position: refs/heads/master@{nodejs#45142} PR-URL: nodejs#13985 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Since V8 5.9 V8 installs a default signal handler for some signals when creating a default platform instance that prints a stack trace. However, Node already does the same thing, so it would seem like the two different stack traces would be printed; also, the V8 handler would lead to a `SIGSEGV` under some circumstances, rather than letting the abort continue normally. Resolve this by disabling V8’s signal handler by default. PR-URL: nodejs#13985 Fixes: nodejs#13865 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message: d8: Make in process stack dumping optional Adds a flag (--disable-in-process-stack-traces) to not install signal handlers so that e.g. ASan signal handlers will work. This flag mirrors chromium's one. R=jochen@chromium.org BUG=chromium:716235 Review-Url: https://codereview.chromium.org/2854173002 Cr-Commit-Position: refs/heads/master@{#45142} PR-URL: #13985 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Since V8 5.9 V8 installs a default signal handler for some signals when creating a default platform instance that prints a stack trace. However, Node already does the same thing, so it would seem like the two different stack traces would be printed; also, the V8 handler would lead to a `SIGSEGV` under some circumstances, rather than letting the abort continue normally. Resolve this by disabling V8’s signal handler by default. PR-URL: #13985 Fixes: #13865 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Since V8 5.9 V8 installs a default signal handler for some signals when creating a default platform instance that prints a stack trace. However, Node already does the same thing, so it would seem like the two different stack traces would be printed; also, the V8 handler would lead to a `SIGSEGV` under some circumstances, rather than letting the abort continue normally. Resolve this by disabling V8’s signal handler by default. PR-URL: nodejs#13985 Fixes: nodejs#13865 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Since V8 5.9 V8 installs a default signal handler for some signals when creating a default platform instance that prints a stack trace. However, Node already does the same thing, so it would seem like the two different stack traces would be printed; also, the V8 handler would lead to a `SIGSEGV` under some circumstances, rather than letting the abort continue normally. Resolve this by disabling V8’s signal handler by default. Backport-PR-URL: #14574 Backport-Reviewed-By: Anna Henningsen <anna@addaleax.net> Backport-Reviewed-By: Refael Ackermann <refack@gmail.com> PR-URL: #13985 Fixes: #13865 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
assuming this doesn't apply to v6.x and 5.1. LMK if I'm mistaken |
Since V8 5.9 V8 installs a default signal handler for some signals when creating a default platform instance that prints a stack trace. However, Node already does the same thing, so it would seem like the two different stack traces would be printed; also, the V8 handler would lead to a `SIGSEGV` under some circumstances, rather than letting the abort continue normally. Resolve this by disabling V8’s signal handler by default. PR-URL: nodejs/node#13985 Fixes: nodejs/node#13865 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Since V8 5.9 V8 installs a default signal handler for some signals
when creating a default platform instance that prints a stack trace.
However, Node already does the same thing, so it would seem like the
two different stack traces would be printed; also, the V8 handler
would lead to a
SIGSEGV
under some circumstances, rather thanletting the abort continue normally.
Fixes: #13865
@nodejs/v8 I don’t have the time to deal with any upstream concerns regarding this, and probably not to look into the segfault as well, so if we want to report it/have that V8 change reverted, somebody else needs to do it.Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
v8
CI: https://ci.nodejs.org/job/node-test-pull-request/8862/