This repository has been archived by the owner on Apr 22, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 7.3k
V8: avoid deadlock when profiling is active #25309
Closed
+70
−0
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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(); |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
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.
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.
@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 isIsolate::GetProcessWideMutexPointer()->TryLock()
returning true in case the process wide mutex is already locked? Shouldn't it return false sinceman pthread_mutex_try_lock
says thatIf the mutex is already locked, pthread_mutex_trylock() will not block waiting for the mutex, but will return an error condition
?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.
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.
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.
@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: isSIGPROF
blocked while runningSignalHandler::HandleProfilerSignal
? Otherwise I imagine there would still be a race condition.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.
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).
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.
@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
:(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:
which suggests that
SIGPROF
is not blocked whenSignalHandler::HandleProfilerSignal
runs. @tunniclm Are we missing something?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.
@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.
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.
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.
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.
@tunniclm Thanks for the clarification, that makes sense 👍
@dmelikyan Agreed, thanks!