-
Notifications
You must be signed in to change notification settings - Fork 15.1k
[debugserver] Remove unnecessary sleep in MachProcess::AttachForDebug #166674
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.
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
Conversation
Remove the unnecessary sleep in MachProcess::AttachForDebug. The preceding comment makes it seem like it's necessary for synchronization, though I don't believe that's the case (see below), and even if it were, sleeping is not a reliable way to achieve that. The reason I don't believe it's necessary is because after we return, we synchronize with the exception thread on a state change. The latter will call and update the process state, which is exactly what we synchronize on. I was able to verify that this is the first time we change the process state: i.e., `GetState` doesn't return a different value before and after the sleep. On top of that, there are 3 more places where we call ptrace attach (`PosixSpawnChildForPTraceDebugging`, `SBLaunchForDebug`, and `BoardServiceLaunchForDebug`) where we don't sleep. rdar://163952037
|
@llvm/pr-subscribers-lldb Author: Jonas Devlieghere (JDevlieghere) ChangesRemove the unnecessary sleep in MachProcess::AttachForDebug. The preceding comment makes it seem like it's necessary for synchronization, though I don't believe that's the case (see below), and even if it were, sleeping is not a reliable way to achieve that. The reason I don't believe it's necessary is because after we return, we synchronize with the exception thread on a state change. The latter will call and update the process state, which is exactly what we synchronize on. I was able to verify that this is the first time we change the process state: i.e., On top of that, there are 3 more places where we call ptrace attach ( rdar://163952037 Full diff: https://github.com/llvm/llvm-project/pull/166674.diff 1 Files Affected:
diff --git a/lldb/tools/debugserver/source/MacOSX/MachProcess.mm b/lldb/tools/debugserver/source/MacOSX/MachProcess.mm
index 3afaaa2f64c00..8df3f29a7e825 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachProcess.mm
+++ b/lldb/tools/debugserver/source/MacOSX/MachProcess.mm
@@ -2853,12 +2853,6 @@ static uint64_t bits(uint64_t value, uint32_t msbit, uint32_t lsbit) {
if (err.Success()) {
m_flags |= eMachProcessFlagsAttached;
- // Sleep a bit to let the exception get received and set our process
- // status
- // to stopped.
- ::usleep(250000);
- DNBLog("[LaunchAttach] (%d) Done napping after ptrace(PT_ATTACHEXC)'ing",
- getpid());
DNBLogThreadedIf(LOG_PROCESS, "successfully attached to pid %d", pid);
return m_pid;
} else {
|
3235423 to
e31e539
Compare
jasonmolenda
left a comment
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.
Yes, agreed. If there ever was a need to sleep to allow something to synchronize, this number was picked fifteen years ago when the whole environment was an order of magnitude slower; it cannot be correct still.
…llvm#166674) Remove the unnecessary sleep in MachProcess::AttachForDebug. The preceding comment makes it seem like it's necessary for synchronization, though I don't believe that's the case (see below), and even if it were, sleeping is not a reliable way to achieve that. The reason I don't believe it's necessary is because after we return, we synchronize with the exception thread on a state change. The latter will call and update the process state, which is exactly what we synchronize on. I was able to verify that this is the first time we change the process state: i.e., `GetState` doesn't return a different value before and after the sleep. On top of that, there are 3 more places where we call ptrace attach (`PosixSpawnChildForPTraceDebugging`, `SBLaunchForDebug`, and `BoardServiceLaunchForDebug`) where we don't sleep. rdar://163952037 (cherry picked from commit fa83723)
…llvm#166674) Remove the unnecessary sleep in MachProcess::AttachForDebug. The preceding comment makes it seem like it's necessary for synchronization, though I don't believe that's the case (see below), and even if it were, sleeping is not a reliable way to achieve that. The reason I don't believe it's necessary is because after we return, we synchronize with the exception thread on a state change. The latter will call and update the process state, which is exactly what we synchronize on. I was able to verify that this is the first time we change the process state: i.e., `GetState` doesn't return a different value before and after the sleep. On top of that, there are 3 more places where we call ptrace attach (`PosixSpawnChildForPTraceDebugging`, `SBLaunchForDebug`, and `BoardServiceLaunchForDebug`) where we don't sleep. rdar://163952037
Remove the unnecessary sleep in MachProcess::AttachForDebug. The preceding comment makes it seem like it's necessary for synchronization, though I don't believe that's the case (see below), and even if it were, sleeping is not a reliable way to achieve that.
The reason I don't believe it's necessary is because after we return, we synchronize with the exception thread on a state change. The latter will call and update the process state, which is exactly what we synchronize on. I was able to verify that this is the first time we change the process state: i.e.,
GetStatedoesn't return a different value before and after the sleep.On top of that, there are 3 more places where we call ptrace attach (
PosixSpawnChildForPTraceDebugging,SBLaunchForDebug, andBoardServiceLaunchForDebug) where we don't sleep.rdar://163952037