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 | ||
|---|---|---|
| 2487 | I don't think this gets called at all. Is the duplicate code here necessary? | |
| source/Plugins/Process/Linux/NativeProcessLinux.cpp | ||
|---|---|---|
| 2135–2151 | 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?