[Lldb-commits] [PATCH] D86388: Fix use-after-free in ThreadPlan, and add test.Background:ThreadPlan objects store a cached pointer to the associated Thread. To quotethe code:// We don't cache the thr

comex created this revision. comex added reviewers: jingham, clayborg. Herald added a subscriber: aaron.ballman. Herald added a project: LLDB. comex requested review of this revision. Herald added a subscriber: JDevlieghere. ...Thread represent // the same underlying object on a later stop. This

[Lldb-commits] [PATCH] D86388: Fix use-after-free in ThreadPlan, and add test.

comex added a comment. In D86388#2234418 , @jingham wrote: > I'm confused as to how this patch actually fixes the problem. When the > thread gets removed from the thread list, it should get Destroy called on it > - which should set m_destroy_called, cau

[Lldb-commits] [PATCH] D86388: Fix use-after-free in ThreadPlan, and add test.

comex added a comment. The sequence I found is: - `WillResume` - `DoResume` sends `eBroadcastBitAsyncContinue` to `ProcessGDBRemote::AsyncThread` - `AsyncThread` calls `process->SetPrivateState(eStateRunning);` - …which sends `eBroadcastBitStateChanged` back to the main thread, handled by `Proc

[Lldb-commits] [PATCH] D86388: Fix use-after-free in ThreadPlan, and add test.

comex added a comment. Disabling the thread list while the target is running sounds like a pretty complex change. For example, what should happen if a Python script calls `lldb.process.GetThreadAtIndex(n)` while the target is running, which currently works? And is it really the right directio