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.

Sign up for GitHub

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

Jump to bottom

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

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 •
edited
Loading

  • 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

This was referenced Jun 22, 2017
Merged
Merged
@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 •
edited
Loading

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 addaleax mentioned this issue Jun 29, 2017
Closed
3 tasks
@addaleax
Copy link
Member

PR: #13985

@Trott Trott mentioned this issue Jun 30, 2017
Closed
2 tasks
addaleax added a commit to addaleax/node that referenced this issue Jun 30, 2017
@addaleax
src: fix process.abort() interaction with V8
9ca4062 
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
@addaleax
src: fix process.abort() interaction with V8
7ed2ba7 
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 <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
addaleax added a commit that referenced this issue Jul 11, 2017
@addaleax
src: fix process.abort() interaction with V8
bb7f734 
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 <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
addaleax added a commit that referenced this issue Jul 18, 2017
@addaleax
src: fix process.abort() interaction with V8
e421f08 
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 <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
addaleax added a commit to targos/node that referenced this issue Jul 21, 2017
@addaleax
src: fix process.abort() interaction with V8
e2ae710 
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 <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
addaleax added a commit that referenced this issue Jul 24, 2017
@addaleax
src: fix process.abort() interaction with V8
89961ba 
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 <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
MylesBorins pushed a commit to MylesBorins/node that referenced this issue Aug 1, 2017
@addaleax @MylesBorins
src: fix process.abort() interaction with V8
f08ea27 
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 <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
addaleax added a commit that referenced this issue Aug 2, 2017
@addaleax
src: fix process.abort() interaction with V8
8a3bc87 
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 <[email protected]>
Backport-Reviewed-By: Refael Ackermann <[email protected]>

PR-URL: #13985
Fixes: #13865
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
hferreiro pushed a commit to brave/node that referenced this issue Sep 27, 2017
@addaleax @hferreiro
src: fix process.abort() interaction with V8
803470e 
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 <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
process Issues and PRs related to the process subsystem. test Issues and PRs related to the tests.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@refack @Trott @addaleax