Turns out there's a bug in the current lldb sources that if you fork, set the stdio file handles to close on exec and then exec lldb with some commands and the `--batch` flag, lldb will stall on exit. The first cause of the bug is that the Python session handler - and probably other places in lldb - think 0, 1, and 2 HAVE TO BE the stdio file handles, and open and close and dup them as needed. NB: I am NOT trying to fix that bug. I'm not convinced running the lldb driver headless is worth a lot of effort, it's just as easy to redirect them to /dev/null, which does work. But I would like to keep lldb from stalling on the way out when this happens. The reason we stall is that we have a MainLoop waiting for signals, and we try to Interrupt it, but because stdio was closed, the interrupt pipe for the MainLoop gets the file descriptor 0, which gets closed by the Python session handler if you run some script command. So the Interrupt fails. We were running the Write to the interrupt pipe wrapped in `llvm::cantFail`, but in a no asserts build that just drops the error on the floor. So then lldb went on to call std::thread::join on the still active MainLoop, and that stalls I made Interrupt (and AddCallback & AddPendingCallback) return a bool for "interrupt success" instead. All the places where code was requesting termination, I added checks for that failure, and skip the std::thread::join call on the MainLoop thread, since that is almost certainly going to stall at this point. I didn't do the same for the Windows MainLoop, as I don't know if/when the WSASetEvent call can fail, so I always return true here. I also didn't turn the test off for Windows. According to the Python docs all the API's I used should work on Windows... If that turns out not to be true I'll make the test Darwin/Unix only.
This adjusts the monitor tear down to only call CancelIoEx a single time, which should cancel all IO operations in the monitoring thread, instead of calling it in a loop. This removes the `m_monitor_thread.native_handle()` call that returns a different type on windows/mingw compiles with pthreads enabled and should fix #162801.
This fixes the following build warnings in a mingw environment:
../../lldb/source/Host/windows/MainLoopWindows.cpp:226:50: warning:
format specifies type 'int' but the argument has type
'IOObject::WaitableHandle' (aka 'void *') [-Wformat]
226 | "File descriptor %d already monitored.", waitable_handle);
| ~~ ^~~~~~~~~~~~~~~
../../lldb/source/Host/windows/MainLoopWindows.cpp:239:49: warning:
format specifies type 'int' but the argument has type 'DWORD' (aka
'unsigned long') [-Wformat]
238 | error = Status::FromErrorStringWithFormat("Unsupported file type
%d",
| ~~
| %lu
239 | file_type);
| ^~~~~~~~~
2 warnings generated.
I wasn't able to build lldb using Mingw-w64 on Windows without changing these 3 lines. It seems like `std::atomic<bool>` wasn't being found without `#include <atomic>` and `ceil` was defaulting to `std::ceil` instead of `std::chrono::ceil`, but I'm not smart enough to know the root cause. I'm sure I'm not the first people to try and compile lldb (and clang and lld) with Mingw-w64 and I don't know if something is wrong with my Mingw-w64, but my changes shouldn't have any affect if they aren't needed.
This should improve synchronizing the MainLoopWindows monitor thread with the main loop state. This uses the `m_ready` and `m_event` event handles to manage when the Monitor thread continues and adds new tests to cover additional use cases. I believe this should fix #147291 but it is hard to ensure a race condition is fixed without running the CI on multiple machines/configurations. --------- Co-authored-by: Pavel Labath <pavel@labath.sk>
As seen on Linaro's Windows on Arm bot.
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\source\Host\windows\MainLoopWindows.cpp(80,25): warning: missing field 'InternalHigh' initializer [-Wmissing-field-initializers]
80 | OVERLAPPED ov = {0};
| ^
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\source\Host\windows\MainLoopWindows.cpp(135,8): warning: 'WillPoll' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
135 | void WillPoll() {
| ^
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\include\lldb/Host/windows/MainLoopWindows.h(40,18): note: overridden virtual function is here
40 | virtual void WillPoll() {}
| ^
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\source\Host\windows\MainLoopWindows.cpp(142,8): warning: 'DidPoll' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
142 | void DidPoll() {
| ^
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\include\lldb/Host/windows/MainLoopWindows.h(41,18): note: overridden virtual function is here
41 | virtual void DidPoll() {}
| ^
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\source\Host\windows\MainLoopWindows.cpp(80,25): warning: missing field 'InternalHigh' initializer [-Wmissing-field-initializers]
80 | OVERLAPPED ov = {0};
| ^
Commit 1a7b7e24bcc1041ae0fb90abcfb73d36d76f4a07 introduced a few casting warnings and a build issue in Win32 platforms. Trying to correct the casts to c++ style casts instead of C style casts.
This updates MainLoopWindows to support events for reading from a pipe (both anonymous and named pipes) as well as sockets. This unifies both handle types using `WSAWaitForMultipleEvents` which can listen to both sockets and handles for change events. This should allow us to unify how we handle watching pipes/sockets on Windows and Posix systems. We can extend this in the future if we want to support watching other types, like files or even other events like a process life time. --------- Co-authored-by: Pavel Labath <pavel@labath.sk>
The windows system APIs only take milliseconds. Make sure we round the sleep interval (in nanoseconds) upwards.