[Lldb-commits] [lldb] [lldb] Re-enable a batched step-over breakpoint after an unreported step (PR #231538)

[Jason Molenda via lldb-commits]

jasonmolenda wrote:

I was looking at a similar failure a few months ago and needed to get back to it.  The problem I was looking at is a VERY hard to hit fail with TestConcurrentManyBreakpoints.py which puts a breakpoint on a worker-function that 100 threads hit.  And the test expects to see the breakpoint hit 100 times.

The problem I would see when I hit this issue was several threads hitting a breakpoint at the same time.  After

```
commit b3c4d44c44237fb8df98f09390e391d16fd3f4b1
Author: Bar Soloveychik <[barsolo at meta.com](mailto:barsolo at meta.com)>
Date:   Mon Mar 2 10:46:23 2026 -0800

    [lldb] Batch breakpoint step-over for threads stopped at the same BP (#183412)
```
https://github.com/llvm/llvm-project/pull/183412 or the RFC https://discourse.llvm.org/t/improving-performance-of-multiple-threads-stepping-over-the-same-breakpoint/89637

lldb will send a single `vCont;s` packet asking to step _n_ threads in one go.

The way debugserver implements this is to set the "instruction step" bit in all _n_ threads, stop all other threads, and tell the process to resume.  The threads will all run on CPU cores as they are available, and when they complete their instruction-step, the kernel creates a Mach Exception that it sends to debugserver to indicate that one of the threads has finished.

The problem is that debugserver doesn't collect all _n_ Mach Exceptions.  As soon as it receives one or more, it sends the result up to lldb.  SOME threads may still be finishing their instruction step -- it entirely depends on how many free cores there are on the machine -- and in fact what I observed a few times was that all _n_ threads had completed the instruction step, but the kernel hadn't yet created the Mach Exception for one of them when debugserver started collecting status.  At this same "stop event", a tiny bit of time later, if I asked debugserver for the exception status of the threads, NOW it had the mach exception for the final thread.

In short, instruction stepping multiple threads -- with debugserver, as it is implemented today -- does not implement this `vCont;s;<multiple-threads>` correctly.  I think debugserver can assume that all _n_ threads will complete their assigned instruction-step eventually, so maybe it should just loop until it receives a mach exception for all _n_ before reporting anything ot lldb.

The other hack idea I had was to have a qSupported flag that debugserver sends saying "don't instruction-step more than one thread at a time" and disable the optimization added via https://github.com/llvm/llvm-project/pull/183412 

https://github.com/llvm/llvm-project/pull/231538