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



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to