src: fix sporadic deadlock in SIGUSR1 handler #5904
Conversation
|
Failure in CI looks related. |
|
The freebsd102-64 one anyway: I'm going to run the CI again because that test has been flaky in the past: https://ci.nodejs.org/job/node-test-pull-request/2073/ |
|
Two failures in CI on freebsd again. |
|
is this relevant to v4, btw? |
|
Yes, v4 is affected. I speculate the freebsd failures are due to libc's sem_post() not being async signal-safe, contrary to what POSIX mandates. It's probably possible to work around that by picking up an alternative implementation from libthr but I need to build up the courage to go in and actually do it. |
|
@bnoordhuis If something scares you then I probably wouldn't know where to start, but if you want to pair on it or if there is something I can do to help let me know |
estliberitas
force-pushed
the
master
branch
2 times, most recently
from
7da4fd4
to
c7066fb
Compare
|
Slightly different take that doesn't use atomics: https://ci.nodejs.org/job/node-test-pull-request/2524/ If that doesn't fix FreeBSD, I'm marking the test flaky on that platform. |
|
@bnoordhuis https://lists.freebsd.org/pipermail/freebsd-current/2014-March/048885.html Tried this PR out in a FreeBSD VM, and removing the |
|
@addaleax Good catch, although that attitude is frustrating: why make writing cross-platform software easier when you can be pedantically correct in your interpretation of the spec? Anyway, I added a workaround, let's see how it fares: https://ci.nodejs.org/job/node-test-pull-request/2537/ |
|
@bnoordhuis I don’t know, they effectively made the minimum stack provided by the pthreads implementation useless for anything but setting up a new stack and seem to know that. Wouldn’t be a fan of that either if I were a regular FreeBSD user. CI is green up to general hickups and the code changes here LGTM. |
Calling v8::Debug::DebugBreak() directly from the signal handler is unsafe because said function tries to grab a mutex. Work around that by starting a watchdog thread that is woken up from the signal handler, which then calls v8::Debug::DebugBreak(). Using a watchdog thread also removes the need to use atomic operations so this commit does away with that. Fixes: nodejs#5368 PR-URL: nodejs#5904 Reviewed-By: Anna Henningsen <[email protected]>
Calling v8::Debug::DebugBreak() directly from the signal handler is unsafe because said function tries to grab a mutex. Work around that by starting a watchdog thread that is woken up from the signal handler, which then calls v8::Debug::DebugBreak(). Using a watchdog thread also removes the need to use atomic operations so this commit does away with that. Fixes: #5368 PR-URL: #5904 Reviewed-By: Anna Henningsen <[email protected]>
|
@bnoordhuis do you think this is safe to land in v4.x? |
|
I'd give it a little longer. It's only been released in v6.2.0 so far. |
|
@bnoordhuis thought on backporting now? |
|
I think it should be good to go now. |
|
@bnoordhuis just tried and it didn't land cleanly, would you be willing to backport? |
|
ping @bnoordhuis for a backport |
Calling v8::Debug::DebugBreak() directly from the signal handler is unsafe because said function tries to grab a mutex. Work around that by starting a watchdog thread that is woken up from the signal handler, which then calls v8::Debug::DebugBreak(). Using a watchdog thread also removes the need to use atomic operations so this commit does away with that. Fixes: nodejs#5368 PR-URL: nodejs#5904 Reviewed-By: Anna Henningsen <[email protected]>
Calling v8::Debug::DebugBreak() directly from the signal handler is unsafe because said function tries to grab a mutex. Work around that by starting a watchdog thread that is woken up from the signal handler, which then calls v8::Debug::DebugBreak(). Using a watchdog thread also removes the need to use atomic operations so this commit does away with that. Fixes: #5368 PR-URL: #5904 Reviewed-By: Anna Henningsen <[email protected]>
Calling v8::Debug::DebugBreak() directly from the signal handler is unsafe because said function tries to grab a mutex. Work around that by starting a watchdog thread that is woken up from the signal handler, which then calls v8::Debug::DebugBreak(). Using a watchdog thread also removes the need to use atomic operations so this commit does away with that. Fixes: #5368 PR-URL: #5904 Reviewed-By: Anna Henningsen <[email protected]>
Calling v8::Debug::DebugBreak() directly from the signal handler is unsafe because said function tries to grab a mutex. Work around that by starting a watchdog thread that is woken up from the signal handler, which then calls v8::Debug::DebugBreak(). Using a watchdog thread also removes the need to use atomic operations so this commit does away with that. Fixes: #5368 PR-URL: #5904 Reviewed-By: Anna Henningsen <[email protected]>
Calling v8::Debug::DebugBreak() directly from the signal handler is unsafe because said function tries to grab a mutex. Work around that by starting a watchdog thread that is woken up from the signal handler, which then calls v8::Debug::DebugBreak(). Using a watchdog thread also removes the need to use atomic operations so this commit does away with that. Fixes: #5368 PR-URL: #5904 Reviewed-By: Anna Henningsen <[email protected]>
Pull Request check-list
make -j8 test(UNIX) orvcbuild test nosign(Windows) pass withthis change (including linting)?
test (or a benchmark) included?
existing APIs, or introduces new ones)?
Affected core subsystem(s)
debugger, test
Description of change
Calling v8::Debug::DebugBreak() directly from the signal handler is
unsafe because said function tries to grab a mutex. Work around that
by starting a watchdog thread that is woken up from the signal handler,
which then calls v8::Debug::DebugBreak().
Fixes: #5368
CI: https://ci.nodejs.org/job/node-test-pull-request/2066/