[lldb/Process/Windows] Attempting to kill exited/detached process in not an error
authorTatyana Krasnukha <tatyana@synopsys.com>
Thu, 30 Jul 2020 17:13:23 +0000 (20:13 +0300)
committerTatyana Krasnukha <tatyana@synopsys.com>
Mon, 3 Aug 2020 09:52:43 +0000 (12:52 +0300)
The lldb test-suite on Windows reports a 'CLEANUP ERROR' when attempting to kill
an exited/detached process. This change makes ProcessWindows consistent with
the other processes which only log the error. After this change a number of
'CLEANUP ERROR' messages are now removed.

Differential Revision: https://reviews.llvm.org/D84957

lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.cpp

index 8a85c8b..07a81cd 100644 (file)
@@ -227,22 +227,20 @@ Status ProcessDebugger::DestroyProcess(const lldb::StateType state) {
     debugger_thread = m_session_data->m_debugger;
   }
 
-  Status error;
-  if (state != eStateExited && state != eStateDetached) {
-    LLDB_LOG(
-        log, "Shutting down process {0}.",
-        debugger_thread->GetProcess().GetNativeProcess().GetSystemHandle());
-    error = debugger_thread->StopDebugging(true);
-
-    // By the time StopDebugging returns, there is no more debugger thread, so
-    // we can be assured that no other thread will race for the session data.
-    m_session_data.reset();
-  } else {
-    error.SetErrorStringWithFormat("cannot destroy process %" PRIx64
-                                   " while state = %d",
-                                   GetDebuggedProcessId(), state);
-    LLDB_LOG(log, "error: {0}", error);
+  if (state == eStateExited || state == eStateDetached) {
+    LLDB_LOG(log, "warning: cannot destroy process {0} while state = {1}.",
+             GetDebuggedProcessId(), state);
+    return Status();
   }
+
+  LLDB_LOG(log, "Shutting down process {0}.",
+           debugger_thread->GetProcess().GetNativeProcess().GetSystemHandle());
+  auto error = debugger_thread->StopDebugging(true);
+
+  // By the time StopDebugging returns, there is no more debugger thread, so
+  // we can be assured that no other thread will race for the session data.
+  m_session_data.reset();
+
   return error;
 }