================
@@ -169,6 +169,38 @@ Status ProcessWindows::DoDetach(bool keep_stopped) {
Log *log = GetLog(WindowsLog::Process);
StateType private_state = GetPrivateState();
if (private_state != eStateExited && private_state != eStateDetached) {
+ if (!keep_stopped) {
+ // if the thread is suspended by lldb, we have to resume threads before
+ // detaching process. When we do after DetachProcess(), thread handles
+ // become invalid so we do before detach.
+ if (private_state == eStateStopped || private_state == eStateCrashed) {
+ LLDB_LOG(log, "process {0} is in state {1}. Resuming for detach...",
+ m_session_data->m_debugger->GetProcess().GetProcessId(),
+ GetPrivateState());
+
+ LLDB_LOG(log, "resuming {0} threads for detach.",
+ m_thread_list.GetSize());
+
+ bool failed = false;
+ for (uint32_t i = 0; i < m_thread_list.GetSize(); ++i) {
+ auto thread = std::static_pointer_cast<TargetThreadWindows>(
+ m_thread_list.GetThreadAtIndex(i));
+ Status result = thread->DoResume();
----------------
anatawa12 wrote:
> Does this mean that if the thread/process gets another exception before we
> manage to detach from it, it will remain suspended?
No, the process will not suspend.
The process will receive the exception and the process handles it instead.
For simple programs, it will crash the process but some process may handle in
their way.
We can see this behavior with TestDetachResumes by reverting
5ad1a98a8b07e1d75829870995fbf36fb8cb99ed.
> I'm not familiar with windows debugging API, so I don't know if there's a way
> to handle this, but I believe this is the reason why linux (and others) have
> a PTRACE_DETACH call which (atomically) detaches from a process/thread _and_
> resumes it.
I agree with that but as far as I researched I could not figure out the API to
detach and resume thread simultaneously.
https://github.com/llvm/llvm-project/pull/115712
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
