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

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

I want to separate out two things here.  One is whether lldb should internally ask questions of a thread once we've invalidated the thread list before running, the other is how we present threads to the user while the process is running.

I was only suggesting restricting  the former.  Once we've put the internal data structure that handles the thread list in an undefined state because we are about to resume, we shouldn't turn around and ask questions of it.  That just seems like a bad practice.

The other question is what does it mean to hand out a thread list when the process is running.  It has to be a historical artifact, right?  We don't actually know that the threads we are handing out still exist, so I'm not really sure what handing them out would mean.  For some platforms we might be able to track threads coming and going, but I'm pretty sure that we can't require that everywhere, os it can't be an essential part of lldb's design.  In general, when the process is "continuing" lldb would like to change its behavior as little as possible, so unless there's a way to keep the thread list accurate while running that doesn't involve stopping and starting the process, we would rather not track this live.  I know that both the Darwin user space and Darwin kernel don't provide such support.

And we can't answer any meaningful questions about the thread without pausing at least that thread.  In non-stop mode, the threads that are running are still in an uncertain state, and only the threads that are stopped are known.  So even when lldb supports keeping some threads running while others are stopped, we'll have to maintain a distinction between the stopped and the running threads, and be clear that to know something about a running thread we'll have to stop it.  In fact, because the point of non-stop debugging is that there are some parts of the system that you really don't want to stop, in that mode we need to be even more careful to be clear about what operations do and don't require stopping the target.

But again, I don't think we need to have that discussion w.r.t. the current problem.  This is all about how we treat our internal state, not what we show to users.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86388/new/

https://reviews.llvm.org/D86388