In the rare event that a thread is created immediately before a breakpoint hit,
the newly created thread and the main thread would be incorrectly resumed
by the creation process.
Details
Diff Detail
Event Timeline
source/Plugins/Process/Linux/NativeProcessLinux.cpp | ||
---|---|---|
2472 | I don't think this gets called at all. Is the duplicate code here necessary? |
source/Plugins/Process/Linux/NativeProcessLinux.cpp | ||
---|---|---|
2136–2145 | It looks to me there might be a race - if you'll be calling this method when TSC inside of ProcessEvent call between RequestStopOnAllRunningThreads() and coordinator.SetPendingNotification() a thread might be mistakenly resumed. So, you may to synchronize IsPendingThreadStop with ProcessEvent(). Can we make RequestThreadResume take additional boolean argument to check for pending stopped state - so, effectively move this conditional logic into EventRequestResume? | |
source/Plugins/Process/Linux/ThreadStateCoordinator.h | ||
152 | This method should be synchronized - GetPendingThreadStopNotification() is used now only within TSC thread and that's why doesn't need synchronization. But if you're going to call it from another thread GetPendingThreadStopNotification should be protected by mutex. |
It looks to me there might be a race - if you'll be calling this method when TSC inside of ProcessEvent call between RequestStopOnAllRunningThreads() and coordinator.SetPendingNotification() a thread might be mistakenly resumed. So, you may to synchronize IsPendingThreadStop with ProcessEvent().
Can we make RequestThreadResume take additional boolean argument to check for pending stopped state - so, effectively move this conditional logic into EventRequestResume?