[Lldb-commits] [PATCH] D62183: [Windows] Fix race condition between state changes

[Martin Andersson via Phabricator via lldb-commits]

martin added a comment.

In D62183#1589937 <https://reviews.llvm.org/D62183#1589937>, @amccarth wrote:

> This change looks fine to me, but I wish there was a reliable way to test it.  Is it a true race condition (e.g., because the unpredictability of thread scheduling), or is there a way to write a test that would always fail without this fix?


My understanding is that this is a race between the call to SetPrivateState(eStateRunning) in DoResume and the call to SetPrivateState(eStateStopped) in OnDebugException (on line 694). The former is supposed to take place before the latter and it often is, but when the latter is run first it leads the debugger to wait indefinitely. Because the second state change is ignored because the process is already in the stopped state.

I found this issue when I was using Visual Studio Code with the lldb-vscode debug adapter. Sometimes when I single stepped I would hit this issue. I could reliably trigger it by holding down F10 <https://reviews.llvm.org/F10> (step) in Visual Studio Code, it would only take a couple of seconds of rapid single stepping (roughly between 10 steps and 100 steps) before I hit it. However, I cannot trigger it with any code. For example, a simple while loop with an integer increment does not trigger it. But if I replace the integer increment with a function call I can trigger it within a couple of seconds. However, I am not familiar enough with LLDB to know if it would be possible to write a test that would reliably trigger it. My hunch is that it would be difficult.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62183/new/

https://reviews.llvm.org/D62183