Skip to content

Investigate SIGSEGV from test/async-hooks/test-callback-error #13865

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
refack opened this issue Jun 22, 2017 · 7 comments
Closed

Investigate SIGSEGV from test/async-hooks/test-callback-error #13865

refack opened this issue Jun 22, 2017 · 7 comments
Labels
process Issues and PRs related to the process subsystem. test Issues and PRs related to the tests.

Comments

@refack
Copy link
Contributor

refack commented Jun 22, 2017

  • Version: 9.pre
  • Platform: Alpine Linux 3.4
  • Subsystem: test,async_hooks,process

docker_alpine34 signaled SIGSEGV

2	async-hooks/test-callback-error	
duration_ms	0.761
severity	fail
stack	|-
assert.js:60
  throw new errors.AssertionError({
  ^

AssertionError [ERR_ASSERTION]: 'SIGSEGV' === 'SIGABRT'
    at ChildProcess.child.on (/home/iojs/build/workspace/node-test-commit-linux/nodes/ubuntu1604_docker_alpine34-64/test/async-hooks/test-callback-error.js:98:14)
    at emitTwo (events.js:125:13)
    at ChildProcess.emit (events.js:213:7)
    at maybeClose (internal/child_process.js:898:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)

Is this a bug or an acceptable value?

Current solution was to mark this test as flaky on Linux.
/cc @gireeshpunathil

Ref: #13527 (different fail on macOS)

@refack refack added process Issues and PRs related to the process subsystem. test Issues and PRs related to the tests. labels Jun 22, 2017
@refack
Copy link
Contributor Author

refack commented Jun 22, 2017

From digging all day into the wierdness that happening in macOS it seems that the different V8_IMMEDIATE_CRASH implementations are doing different thing on different platform and for different compilers on the same platform, so maybe it's not that strange 🤷‍♂️ especialy since Alpine Linux does not use glibc but rather musl libc

@Trott
Copy link
Member

Trott commented Jun 27, 2017

/cc @nodejs/docker

@Trott
Copy link
Member

Trott commented Jun 27, 2017

/cc @nodejs/async_hooks

@Trott
Copy link
Member

Trott commented Jun 28, 2017

/cc @nodejs/build

@Trott
Copy link
Member

Trott commented Jun 28, 2017

/cc @nodejs/testing

@addaleax
Copy link
Member

addaleax commented Jun 28, 2017

I still have SSH access to one of the machines, and this is how far I’ve traced it:

$ ./node -e 'process.abort()'
Received signal 6
[end of stack trace]
Segmentation fault (core dumped)

It appears the segfault occurs within abort(). I’ll try to see what else I can find out, but the docker container being a docker container makes debugging a bit more difficult than what I’m used to.

it seems that the different V8_IMMEDIATE_CRASH implementations are doing different thing on different platform and for different compilers on the same platform, so maybe it's not that strange

I am pretty sure V8_IMMEDIATE_CRASH is not involved here. I am no longer pretty sure. 😄

@addaleax
Copy link
Member

PR: #13985

addaleax added a commit to addaleax/node that referenced this issue Jun 30, 2017
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
@Trott Trott closed this as completed in 4dff05f Jul 2, 2017
addaleax added a commit to addaleax/node that referenced this issue Jul 3, 2017
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>
addaleax added a commit that referenced this issue Jul 11, 2017
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>
addaleax added a commit that referenced this issue Jul 18, 2017
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>
addaleax added a commit to targos/node that referenced this issue Jul 21, 2017
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>
addaleax added a commit that referenced this issue Jul 24, 2017
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>
MylesBorins pushed a commit to MylesBorins/node that referenced this issue Aug 1, 2017
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>
addaleax added a commit that referenced this issue Aug 2, 2017
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>
hferreiro pushed a commit to brave/node that referenced this issue Sep 27, 2017
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>
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
process Issues and PRs related to the process subsystem. test Issues and PRs related to the tests.
Projects
None yet
Development

No branches or pull requests

3 participants