Bug ID 28742
Summary Make Process::StopForDestroyOrDetach handle interrupting RunThreadPlan more robustly
Product lldb
Version unspecified
Hardware PC
OS All
Status NEW
Severity normal
Priority P
Component All Bugs
Assignee lldb-dev@lists.llvm.org
Reporter jingham@apple.com
CC llvm-bugs@lists.llvm.org
Classification Unclassified
See the discussion in commit r276795. As Pavel said there:
This case is fine. The tricky part is the opposite:
- we check the private state, see that it is stopped and decide that
we have nothing to do
- meanwhile, the private state flips back to running (e.g. because it
was just temporarily stopped while it was stepping over a breakpoint)
- RunThreadPlan carries on running oblivious to the fact that someone
tried to interrupt it
- process does not stop
So the Process has to have a way to flag that RunThreadPlan should interrupt
it's work. This is a little tricky because, if you need to send a signal to
interrupt but the process stops with the signal pending, you will also need to
pull off that signal or when you detach it will go to the process and likely
kill it.