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

Reply via email to