labath added inline comments.
================ Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1918 + } else { + // This can happen if one of the events is an main thread exit. + LLDB_LOG(log, "... but the thread has disappeared"); ---------------- mgorny wrote: > labath wrote: > > mgorny wrote: > > > Are we talking about some kind of race here? Or some thread that appears > > > in `m_threads` but is not returned by `GetThreadByID()`? > > > > > > I was wondering if you could use thread pointers as keys. > > The problem is when a thread disappears. This can happen in case of a main > > thread exit or an execve, in which case we remove all non-main threads from > > the list. However, we can still have some pending events for the other > > threads. Now, I haven't managed to reproduce this in my experiments, but > > the manpage is adamant that a SIGKILL should immediately terminate a > > process. In my (limited) tests the debugger always got a PTRACE_EVENT_EXIT > > stop for each threads (which is again something that the manpage says > > should not happen), so we theoretically (with careful management of thread > > lifetimes) might ensure that a thread with pending events does not > > disappear, but depending on it doesn't seem like a good idea. > Hmm, so it could disappear while `MonitorCallback()` is executing; do I > understand correctly? Yes. I meant disappearing from the list we maintain, not from the system. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D116372/new/ https://reviews.llvm.org/D116372 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits