Fix for potential infinite loop in TCP traffic simulator.

For stream sizes that were not multiple of 4, we could end up causing
a size_t wraparound which resulted in an infinite loop.

Bug: webrtc:9510
Change-Id: Ie3fe5345e1477efa6a4ec338bd9f9b00225e688e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177005
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31503}

1 files changed, 7 insertions, 6 deletions

diff --git a/test/network/cross_traffic.cc b/test/network/cross_traffic.cc
index be0c3d3286..56e7635142 100644
--- a/test/network/cross_traffic.cc
+++ b/test/network/cross_traffic.cc
@@ -144,15 +144,16 @@ void TcpMessageRouteImpl::SendMessage(size_t size,
           cwnd_ = 10;
           ssthresh_ = INFINITY;
         }
-        size_t data_left = size;
-        size_t kMaxPacketSize = 1200;
-        size_t kMinPacketSize = 4;
+        int64_t data_left = static_cast<int64_t>(size);
+        int64_t kMaxPacketSize = 1200;
+        int64_t kMinPacketSize = 4;
         Message message{std::move(handler)};
         while (data_left > 0) {
-          size_t packet_size =
-              std::max(kMinPacketSize, std::min(data_left, kMaxPacketSize));
+          int64_t packet_size = std::min(data_left, kMaxPacketSize);
           int fragment_id = next_fragment_id_++;
-          pending_.push_back(MessageFragment{fragment_id, packet_size});
+          pending_.push_back(MessageFragment{
+              fragment_id,
+              static_cast<size_t>(std::max(kMinPacketSize, packet_size))});
           message.pending_fragment_ids.insert(fragment_id);
           data_left -= packet_size;
         }