[LLDB][ProcessWindows] Set exit status on instance rather than going through all targets

[Nerixyz]

When quitting LLDB on Windows while a process was still running, LLDB would take unusually long to exit. This was due to a temporary deadlock:

The main thread was destroying the processes. In doing so, it iterated over the target list:

llvm-project/lldb/source/Core/Debugger.cpp

Lines 1095 to 1098 in 88c64f7

	for (TargetSP target_sp : m_target_list.Targets()) {
	if (target_sp) {
	if (ProcessSP process_sp = target_sp->GetProcessSP())
	process_sp->Finalize(false /* not destructing */);

This locks the list for the whole iteration. Finalizing the process would eventually lead to DebuggerThread::StopDebugging, which terminates the process and waits for it to exit:

llvm-project/lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp

Line 196 in 88c64f7

DWORD wait_result = WaitForSingleObject(m_debugging_ended_event, 5000);

The debugger loop (on a separate thread) would see that the process exited and call ProcessWindows::OnExitProcess. This calls the static function Process::SetProcessExitStatus. This tries to find the process by its ID from the debugger's target list. Doing so requires locking the list, so the debugger thread would then be stuck on

llvm-project/lldb/source/Target/TargetList.cpp

Line 403 in 0a7a7d5

std::lock_guard<std::recursive_mutex> guard(m_target_list_mutex);

After 5s, the main thread would give up waiting. So every exit where the process was still running would be delayed by about 5s.

Since ProcessWindows would find itself when calling SetProcessExitStatus, we can call SetExitStatus directly.

This can also make some tests run faster. For example, the DIA PDB tests previously took 15s to run on my PC (24 jobs) and now take 5s. For all shell tests, the difference isn't that big (only about 3s), because most don't run into this and the tests run in parallel.

[llvmbot]

@llvm/pr-subscribers-lldb

Author: nerix (Nerixyz)

Changes

When quitting LLDB on Windows while a process was still running, LLDB would take unusually long to exit. This was due to a temporary deadlock:

The main thread was destroying the processes. In doing so, it iterated over the target list:

llvm-project/lldb/source/Core/Debugger.cpp

Lines 1095 to 1098 in 88c64f7

	for (TargetSP target_sp : m_target_list.Targets()) {
	if (target_sp) {
	if (ProcessSP process_sp = target_sp->GetProcessSP())
	process_sp->Finalize(false /* not destructing */);

This locks the list for the whole iteration. Finalizing the process would eventually lead to DebuggerThread::StopDebugging, which terminates the process and waits for it to exit:

llvm-project/lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp

Line 196 in 88c64f7

DWORD wait_result = WaitForSingleObject(m_debugging_ended_event, 5000);

The debugger loop (on a separate thread) would see that the process exited and call ProcessWindows::OnExitProcess. This calls the static function Process::SetProcessExitStatus. This tries to find the process by its ID from the debugger's target list. Doing so requires locking the list, so the debugger thread would then be stuck on

llvm-project/lldb/source/Target/TargetList.cpp

Line 403 in 0a7a7d5

std::lock_guard<std::recursive_mutex> guard(m_target_list_mutex);

After 5s, the main thread would give up waiting. So every exit where the process was still running would be delayed by about 5s.

Since ProcessWindows would find itself when calling SetProcessExitStatus, we can call SetExitStatus directly.

This can also make some tests run faster. For example, the DIA PDB tests previously took 15s to run on my PC (24 jobs) and now take 5s. For all shell tests, the difference isn't that big (only about 3s), because most don't run into this and the tests run in parallel.

---

Full diff: https://github.com/llvm/llvm-project/pull/159308.diff

1 Files Affected:

• (modified) lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp (+1-1)

diff --git a/lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp b/lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
index 27530f032ce51..0fecefe23b88e 100644
--- a/lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
+++ b/lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
@@ -666,7 +666,7 @@ void ProcessWindows::OnExitProcess(uint32_t exit_code) {
     target->ModulesDidUnload(unloaded_modules, true);
   }
 
-  SetProcessExitStatus(GetID(), true, 0, exit_code);
+  SetExitStatus(exit_code, /*exit_string=*/"");
   SetPrivateState(eStateExited);
 
   ProcessDebugger::OnExitProcess(exit_code);

[DavidSpickett]

Great find! I had noticed that lldb was slow to quit but I always thought it would be something inherent to how things work on Windows.

[mstorsjo]

Nice, thanks! I've also observed this from time to time, but haven't had time to dig into it!

[mstorsjo]

Do you think it'd make sense to backport this fix to 21.x?

[Nerixyz]

Do you think it'd make sense to backport this fix to 21.x?

That could make sense, and I'm fine with doing this, though, the bug was already in 20.x. Maybe @DavidSpickett has some thoughts on this?

[DavidSpickett]

It always "worked", just slowly. So it's like backporting a code generation improvement, which we have been known to do. Worth a try.

I would support it on the basis that the patch is very simple and we haven't seen any regressions.

[Nerixyz]

/cherry-pick a868f28

[llvmbot]

/pull-request #161541

[mstorsjo]

Yeah - it doesn't need to be a regression in 21.x for the fix to be backported, any reasonable bug fix can be eligible IMO.