Fix segfault when PeerConnection is destroyed during stats collection.

webrtc/api/peerconnection.cc

Index: webrtc/api/peerconnection.cc
diff --git a/webrtc/api/peerconnection.cc b/webrtc/api/peerconnection.cc
index ebce40ca5eb0cf37d03243663826ea911eda06c3..58174f08c11bbd10d36e58c3420a3d06ff8b909e 100644
--- a/webrtc/api/peerconnection.cc
+++ b/webrtc/api/peerconnection.cc
@@ -608,6 +608,10 @@ PeerConnection::~PeerConnection() {
   }
   // Destroy stats_ because it depends on session_.
   stats_.reset(nullptr);
+  if (stats_collector_) {
+    stats_collector_->WaitForPendingRequest();

[Taylor Brandstetter, 2016/12/16 18:53:27]

nit: I'd just put this in the RTCStatsCollector destructor instead of making it
a public method. But I do see the reasoning of "a destructor shouldn't be doing
things like waiting for other threads".

If you choose to leave it like this, could you add something like:

RTC_DCHECK(num_pending_partial_reports_ == 0) << "You must call
WaitForPendingRequest before safely destroying the RTCStatsCollector."

... in the RTCStatsCollector destructor? And leave a comment in the header
saying WaitForPendingRequest must be called before safely destroying?

[hbos, 2016/12/19 09:52:48]

It's not that you have to wait before destroying the collector, in fact the
collector is reference counted and will not be destroyed during a pending
request by design. The wait is to ensure that resources the collector is relying
on (that are not reference counted or owned by the collector) are not destroyed,
e.g. making sure PeerConnection and friends is not destroyed before the
collector.

I added a DCHECK, but if it is ever hit we have a bug and not just a problem of
not calling WaitForPendingRequest.

That said, now that we have a WaitForPendingRequests we could remove the
reference counting if we wanted to (not in this CL).

+    stats_collector_ = nullptr;
+  }
   // Now destroy session_ before destroying other members,
   // because its destruction fires signals (such as VoiceChannelDestroyed)
   // which will trigger some final actions in PeerConnection...