In SendContinuePacketAndWaitForResponse there is a special bit of

code that looks for a second stop-reply packet in response to an
interrupt (control-c).  This is to handle the case where where a
stop packet is making its way up to lldb right as lldb decides to
interrupt the inferior.  If the inferior is running and we interrupt
it, we'd expect a T11 type response meaning that the inferior halted
because of the interrupt.  But if the interrupt gets a T05 type
response instead, meaning that we stopped execution by hitting a
breakpoint or whatever, then the interrupt was received while the
inferior was already paused and so it is treated as a "?" packet
-- the remote stub will send the stop message a second time.

There's a timeout where we wait to get this second stop reply packet
in SendContinuePacketAndWaitForResponse, currently 1ms.  For a slow
remote target, it may take longer than that to send the second stop
reply packet.  If that happens, then lldb will use that second stop
reply packet as the response for the next packet request it makes 
to the remote stub.  The two will be out of sync by one packet for
the rest of the debug session and it's going to go badly from then on.

I've seen times as slow as 46ms, and given the severity of missing that
second stop reply packet, I'm increasing the timeout to 100ms, or 0.1sec.
<rdar://problem/21990791> 

llvm-svn: 246004

1 files changed, 2 insertions, 2 deletions

diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
index cd7f0fef8dc..ab0867ded61 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -1133,10 +1133,10 @@ GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse
                                 continue_after_async = false;
 
                                 // We didn't get a SIGINT or SIGSTOP, so try for a
-                                // very brief time (1 ms) to get another stop reply
+                                // very brief time (0.1s) to get another stop reply
                                 // packet to make sure it doesn't get in the way
                                 StringExtractorGDBRemote extra_stop_reply_packet;
-                                uint32_t timeout_usec = 1000;
+                                uint32_t timeout_usec = 100000;
                                 if (ReadPacket (extra_stop_reply_packet, timeout_usec, false) == PacketResult::Success)
                                 {
                                     switch (extra_stop_reply_packet.GetChar())