Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

V8: avoid deadlock when profiling is active #25309

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions deps/v8/src/isolate.h
Original file line number Diff line number Diff line change
Expand Up @@ -384,6 +384,11 @@ class Isolate {
public:
~Isolate();

// ISSUE-14576: allow to access process_wide_mutex_ from sampler.cc
static base::Mutex* GetProcessWideMutexPointer() {
return process_wide_mutex_.Pointer();
}

// A thread has a PerIsolateThreadData instance for each isolate that it has
// entered. That instance is allocated when the isolate is initially entered
// and reused on subsequent entries.
Expand Down
8 changes: 8 additions & 0 deletions deps/v8/src/sampler.cc
Original file line number Diff line number Diff line change
Expand Up @@ -342,6 +342,14 @@ void SignalHandler::HandleProfilerSignal(int signal, siginfo_t* info,
// We require a fully initialized and entered isolate.
return;
}

// ISSUE-14576: To avoid deadlock, return if there is a thread lock
if (Isolate::GetProcessWideMutexPointer()->TryLock()) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we check for a NULL pointer here? I guess that it's very unlikely to happen, but it seems safer to have the check than not have it.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dmelikyan @tunniclm Also, I'm still not sure I properly this fix. What is already locking the process wide mutex in the profiler thread when isolate->thread_manager()->IsLockedByCurrentThread() is called? Also, why is Isolate::GetProcessWideMutexPointer()->TryLock() returning true in case the process wide mutex is already locked? Shouldn't it return false since man pthread_mutex_try_lock says that If the mutex is already locked, pthread_mutex_trylock() will not block waiting for the mutex, but will return an error condition?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TryLock returns false if it wasn't able to acquire lock. In this case we should return, otherwise a deadlock may happen. This is the point of the fix. The code on the next line, IsLockedByCurrentThread(), which ends up calling EnsureInitialized(), does lock, which results in a deadlock (as described in the pull request comment) and so I made sure it doesn't get there. Starting V8 version 3.29.79 the EnsureInitialized() call was removed from GetCurrentThreadId(), which fixes the deadlock problem automatically and this fix is not required anymore.

Concerning NULL pointer, it shouldn't be the case, otherwise IsLockedByCurrentThread() would also throw NULL pointer.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dmelikyan Right, I understand the rationale behind your fix now, thank you for the clarification.

What is already locking the process wide mutex in the profiler thread when SignalHandler::HandleProfilerSignal is called? Possibly related question: is SIGPROF blocked while running SignalHandler::HandleProfilerSignal? Otherwise I imagine there would still be a race condition.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are different places where the lock is acquired by the same thread, I've seen different stacks with gdb.

Not sure how/if SIGPROF is blocked, I think not, because it is fired once every millisecond (every 10ms on Android).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dmelikyan According to different man pages (like http://man7.org/linux/man-pages/man2/sigaction.2.html, but also on OSX, I haven't looked on other platforms) and other sources, including "Advanced Programming In the Unix Environment" from Richard Stevens, it seems that sigaction:

guarantee[s] that whenever we are processing a given signal, another occurrence of that same signal is blocked until we're finished processing the first occurrence.

(that's an excerpt from the book mentioned above).

So I would think that your approach is safe.

However @tunniclm mentioned in one of his comments that he investigated:

Block[ing] the SIGPROF signal using pthread_sigmask() while acquiring and releasing the process_wide_mutex_

which suggests that SIGPROF is not blocked when SignalHandler::HandleProfilerSignal runs. @tunniclm Are we missing something?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@misterdjules This was instead of, rather than in addition to the pthread_mutex_trylock() approach. Blocking was not added inside the signal handler, but rather around the code in the rest of the system that called pthread_mutex_lock() and pthread_mutex_unlock() (on the process_wide_mutex_) so that when the signal occurs it it will never interrupt those calls to ...lock()/..unlock().

I wanted to make sure that was documented in case we find a there is a rare race condition and we need a way to close it. As for now, I couldn't find a problem in my testing of the fix we have here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By blocking SIGPROF we're altering V8's original logic to some extent. I wouldn't do it and keep the patch only fixing the actual deadlock problem.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tunniclm Thanks for the clarification, that makes sense 👍

@dmelikyan Agreed, thanks!

Isolate::GetProcessWideMutexPointer()->Unlock();
} else {
return;
}

if (v8::Locker::IsActive() &&
!isolate->thread_manager()->IsLockedByCurrentThread()) {
return;
Expand Down
57 changes: 57 additions & 0 deletions test/simple/test-regress-GH-14576.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
// Copyright Joyent, Inc. and other Node contributors.
//
// Permission is hereby granted, free of charge, to any person obtaining a
// copy of this software and associated documentation files (the
// "Software"), to deal in the Software without restriction, including
// without limitation the rights to use, copy, modify, merge, publish,
// distribute, sublicense, and/or sell copies of the Software, and to permit
// persons to whom the Software is furnished to do so, subject to the
// following conditions:
//
// The above copyright notice and this permission notice shall be included
// in all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
// OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
// NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
// DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
// OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
// USE OR OTHER DEALINGS IN THE SOFTWARE.

/*
* Tests for sampler deadlock regression.
* Issue https://github.com/joyent/node/issues/14576
*/

var assert = require('assert');
var cp = require('child_process');

var child = undefined;

if (process.platform !== 'win32') {
process.on('SIGTERM', function() {
if(child) {
process.kill(child.pid, 'SIGKILL');
}

process.exit();
});
}

var testScript = "var i = 0; function r() { if(++i > 25) return; " +
"setTimeout(r, 1); }; r();"
var nodeCmd = process.execPath +
' --prof --nologfile_per_isolate' +
' -e "' + testScript + '"';
var runs = 0;

function runTestScript() {
child = cp.exec(nodeCmd, function(err, stdout, stderr) {
if (++runs > 50) return;

runTestScript();
});
}

runTestScript();