Fix possible race between the stats collector and transport controller
Previously, it would be possible for the RTCStatsCollector to start
an async network task to gather stats that would be run after the
PeerConnection was closed when the transport controller was set to
null.
Bug: chromium:829238
Change-Id: I22fb4ce603caf2614814780b95b62127cee28284
Reviewed-on: https://webrtc-review.googlesource.com/72525
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23046}diff --git a/pc/peerconnection.cc b/pc/peerconnection.cc
index fa2ba7c..b7fe2e3 100644
--- a/pc/peerconnection.cc
+++ b/pc/peerconnection.cc
@@ -3210,6 +3210,15 @@
for (auto transceiver : transceivers_) {
transceiver->Stop();
}
+
+ // Ensure that all asynchronous stats requests are completed before destroying
+ // the transport controller below.
+ if (stats_collector_) {
+ stats_collector_->WaitForPendingRequest();
+ }
+
+ // Don't destroy BaseChannels until after stats has been cleaned up so that
+ // the last stats request can still read from the channels.
DestroyAllChannels();
// The event log is used in the transport controller, which must be outlived
