[all-commits] [llvm/llvm-project] 5ce6d3: [lldb][Darwin] Don't mark threads as having hit bp...

[Jason Molenda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5ce6d3a2423ef046b5d1d5e9ec699dd9fe7af377
      https://github.com/llvm/llvm-project/commit/5ce6d3a2423ef046b5d1d5e9ec699dd9fe7af377
  Author: Jason Molenda <jmolenda at apple.com>
  Date:   2026-09-10 (Thu, 10 Sep 2026)

  Changed paths:
    M lldb/packages/Python/lldbsuite/test/gdbclientutils.py
    M lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
    M lldb/test/API/functionalities/gdb_remote_client/TestBatchedBreakpointStepOver.py
    A lldb/test/API/functionalities/gdb_remote_client/TestBreakpointNotHit.py
    M lldb/test/API/functionalities/gdb_remote_client/TestMSP430MSPDebug.py
    M lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentManyBreakpoints.py

  Log Message:
  -----------
  [lldb][Darwin] Don't mark threads as having hit bp if not (#222488)

When a multithreaded program stops exeuction with a mach exception on
more than one thread, if one of the threads is *at* a breakpoint site,
but hasn't *hit* the breakpoint yet, lldb was incorrectly stepping over
the breakpoint instruction when it resumed execution. This would result
in TestConcurrentManyBreakpoints reporting that a breakpoint hit on 100
threads was only hit 99 times, because one of the breakpoints was
silently stepped past without being counted.

The bug happened because on Darwin/debugserver systems the stop info
packet includes a `jstopinfo` which is a JSON dictionary of all threads
that have an exception. When `jstopinfo` is present, ProcessGDBRemote
was initializing any thread not included in `jstopinfo` as having an
empty StopInfo. It did this without checking if we are _at_ a breakpoint
site, and marking the thread as "Stopped at unexecuted breakpoint
instruction". Because the threads now had an empty StopInfo already, the
other places where we might check "if stopped at unexecuted breakpoint
instruction" were never executed.

I created a gdb_remote_client API test with a synthetic test case where
four threads stop at a breakpoint; three of them have hit the
breakpoint, one has not. And confirm that lldb only registers 3
breakpoint hits initially, and then the 4th as we resume. Debugging the
"99 breakpoints hit instead of 100" failures was tricky and involved
running the test in a loop on a heavily loaded machine to get the
necessary timing, and it was easy to give up, so I wanted a much simpler
synthetic case to show the problem if we might regress.

rdar://180565704



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications