[all-commits] [llvm/llvm-project] c2939b: Reland "[lldb] Clear thread-creation breakpoints i...

[Felipe de Azevedo Piovezan via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c2939b9bf672713ac36910a3e6d00c19ace1bd44
      https://github.com/llvm/llvm-project/commit/c2939b9bf672713ac36910a3e6d00c19ace1bd44
  Author: Felipe de Azevedo Piovezan <fpiovezan at apple.com>
  Date:   2025-04-11 (Fri, 11 Apr 2025)

  Changed paths:
    M lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
    M lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
    M lldb/test/API/macosx/thread_start_bps/TestBreakpointsThreadInit.py

  Log Message:
  -----------
  Reland "[lldb] Clear thread-creation breakpoints in ProcessGDBRemote::Clear (#134397)" (#135296)

This reapplies commit
https://github.com/llvm/llvm-project/commit/232525f06942adb3b9977632e38dcd5f08c0642d.

The original commit triggered a sanitizer failure when `Target` was
destroyed. In `Target::Destroy`, `DeleteCurrentProcess` was called, but
it did not destroy the thread creation breakpoints for the underlying
`ProcessGDBRemote` because `ProcessGDBRemote::Clear` was not called in
that path.

`Target `then proceeded to destroy its breakpoints, which resulted in a
call to the destructor of a `std::vector` containing the breakpoints.
Through a sequence of complicated events, destroying breakpoints caused
the reference count of the underlying `ProcessGDBRemote` to finally
reach zero. This, in turn, called `ProcessGDBRemote::Clear`, which
attempted to destroy the breakpoints. To do that, it would go back into
the Target's vector of breakpoints, which we are in the middle of
destroying.

We solve this by moving the breakpoint deletion into
`Process:DoDestroy`, which is a virtual Process method that will be
called much earlier.



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