Bug ID 37294
Summary lldb-server can deadlock in ack-mode
Component All Bugs
lldb-server is a single-threaded event-driven app and uses the MainLoop class to manage events and their actions. It's two main sources of events are a network socket (requests from the client) and SEGV signals (events in the inferior). Normally everything works fine, if we have a very fast client (or a heavily loaded system) which tries to communicate with lldb-server in ack-mode, things can break down. The sequence of events if approximately like this: 1. inferior stops for some reason (event A) 2. lldb-server sends a stop-reply packet 3. lldb-server waits for acknowledgement from the client. - now if the client is really fast, he will manage to also send a regular packet in addition to a acknowledgement 4. GetAck will read both of these things, but process only the acknowledgement, and store the rest in a side buffer 5. event A processing done, mainloop calls ppoll() - at this point, we should wake up and process the client request, however, ppoll blocks because as far as it is concerned, the event has already been processed - so server blocks waiting for data, and client blocks waiting for the server to respond - deadlock. I have a couple of ideas how to fix this, but none of them seemed completely appealing. This issue only affects the lldb-server gtests, because they are the only ones running in ack-mode. Given that this was more of an omission than explicit intent, I am going to switch the tests to noack-mode as a stop-gap measure, to make sure the tests are not flaky.