Solve hang on Windows when lldb fails to launch the process

[amccarth]

Summary

The DebuggerThread was detecting the launch error, but it was ignored by ProcessWindows::DoLaunch, causing lldb to wait forever in the debugger loop.

Found while diagnosing test problems.

[zturner]

Interesting. The change looks correct. Out of curiosity, what was the error launching the process? based on the arguments that were used to attempt CreateProcess(), should the launch have succeeded under normal circumstances? Maybe we were launching a process with a bogus path or something?

[amccarth]

In D7874#129394, @zturner wrote:

Interesting. The change looks correct. Out of curiosity, what was the error launching the process? based on the arguments that were used to attempt CreateProcess(), should the launch have succeeded under normal circumstances? Maybe we were launching a process with a bogus path or something?

Yes, the case I debugged was specifying a non-existent working directory. For example:

(lldb) process launch -w c:\does_not_exist

At least one of the process_launch tests does this. The test also fails for other reasons, which I'm working on. Since I'd seen the hang myself when learning to use lldb interactively, I thought it was worth a separate fix.

[zturner]

Ahh. So it was specifically testing that launching a process from a non-existant directory failed in the correct way? If it was testing something else, then that alone seems like a useful test to add.

[amccarth]

Yes, the test was explicitly trying to set the working directory of the
inferior process to a non-existent directory. (The working directory of
lldb was valid and contained the target image.)

The failure reported up is 0x0000010b, which corresponds to "The directory
name is invalid." Unfortunately, lldb simply reports "error: process
launch failed: unknown error". I assume there's still a task to get the
WinAPI errors reported up through the UI.

[zturner]

Yea, if you look at Error.h / Error.cpp, there's functions like SetError() and GetMessage(). Currently error strings are not reported at all unless you explicitly set a string. But there's no reason it couldn't ask the system to do the conversion if it's on a platform where the error code makes sense (depending on the category). Just hasn't been done yet, but it's definitely something we should do at some point.

lldb/trunk/source/Plugins/Process/Windows/ProcessWindows.cpp

ProcessWindows::DoLaunch(Module *exe_module,
     // Kick off the DebugLaunch asynchronously and wait for it to complete.
     result = debugger->DebugLaunch(launch_info);
 
     HostProcess process;
     if (result.Success())
     {
         // Block this function until we receive the initial stop from the process.
         if (::WaitForSingleObject(m_session_data->m_initial_stop_event, INFINITE) == WAIT_OBJECT_0)
+        {
             process = debugger->GetProcess();
+            if (m_session_data->m_launch_error.Fail())
+                result = m_session_data->m_launch_error;
+        }
         else
             result.SetError(::GetLastError(), eErrorTypeWin32);
     }
 
     if (!result.Success())
         return result;
 
     // We've hit the initial stop.  The private state should already be set to stopped as a result