[Reproducers] Fix GDB remote flakiness during replay
authorJonas Devlieghere <jonas@devlieghere.com>
Fri, 22 Mar 2019 23:33:17 +0000 (23:33 +0000)
committerJonas Devlieghere <jonas@devlieghere.com>
Fri, 22 Mar 2019 23:33:17 +0000 (23:33 +0000)
commit528ce4dd986776331571880dbc1636ac102a5723
tree982000424df71dd2217a4987fa03d69091776bd7
parentec74378e93febd5414f30cf2e833eb3ce9273717
[Reproducers] Fix GDB remote flakiness during replay

This fixes the flakiness of the GDB remote reproducer during replay. It
was caused by a combination sending one ACK to many from the replay
server and the code that "flushes" any queued GDB remote packets in
GDBRemoteCommunicationClient::HandshakeWithServer.

The spurious ACK was the result of combining both implicit and explicit
handling of ACKs in the replay server. The handshake consists of an ACK
followed by an QStartNoAckMode. As long as we haven't seen any
QStartNoAckMode, we were sending implicit acknowledgments. So the first
ACK got acknowledged twice, once implicitly, and once as part of the
replay.

The reason we didn't notice this was the code in HandshakeWithServer
that "waits for any responses that might have been queued up in the
remote GDB server and flush them all". A 10ms timeout is used to move on
when no packets are left. If the second ACK didn't make it within those
10ms, all packets were offset by one.

llvm-svn: 356825
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationReplayServer.cpp