summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/TextAPI
diff options
context:
space:
mode:
authorJonas Devlieghere <jonas@devlieghere.com>2019-03-22 23:33:17 +0000
committerJonas Devlieghere <jonas@devlieghere.com>2019-03-22 23:33:17 +0000
commit528ce4dd986776331571880dbc1636ac102a5723 (patch)
tree982000424df71dd2217a4987fa03d69091776bd7 /llvm/unittests/TextAPI
parentec74378e93febd5414f30cf2e833eb3ce9273717 (diff)
downloadbcm5719-llvm-528ce4dd986776331571880dbc1636ac102a5723.tar.gz
bcm5719-llvm-528ce4dd986776331571880dbc1636ac102a5723.zip
[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
Diffstat (limited to 'llvm/unittests/TextAPI')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud