barsolo2000 wrote: @JDevlieghere The non determinism comes from the gap between the barrier release and each thread executing the trap instruction. So basically, we spawn 10 threads that synchronize at a `pseudo_barrier_wait`. When all 10 arrive at the barrier, then they're released in the same time and all proceed twards the bp line. but "simultaneously" only means they all start running. When the first thread executes the trap and generates a `SIGTRAP`, the kernel delivers the signal and LLDB stops all threads. at that point, some threads may have also executed the trap but some may still be a few instructions away (they were released from the barriers but haven't reached the bp PC yet). Those threads are NOT at the breakpoint address, so `SetupToStepOverBreakpointIfNeeded` doesn't create plans for them, and they don't join the batch. So if only 6 out of 10 threads reached the breakpoint before the stop, only 6 get batched. The other 4 resume normally, hit the breakpoint on the next continue, and get stepped over individually or in a smaller batch.
The flaky test is dependent all some things that are out of my control, but there is another test (the mock server test) that eliminates this issue, it reports all 10 threads as stopped at the breakpoint address in the stop reply, so LLDB always sees all 10 at the breakpoint. To make the integration test stronger without being flaky, we could make the assertions relative to what actually happened, basically count how many threads LLDB actually saw at the breakpoint (from the "Registered thread" log messages) and verify the z0/Z0 counts match that group size, rather than comparing against the total thread count. let me know if you would want me to do it, or the fix + the already existing test (the second test) are sufficient. https://github.com/llvm/llvm-project/pull/182415 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
