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..f78825e69afa252cc81423154f9f8454fb6ea437 100644
--- a/webrtc/api/peerconnection.cc
+++ b/webrtc/api/peerconnection.cc
@@ -608,6 +608,8 @@ PeerConnection::~PeerConnection() {
   }
   // Destroy stats_ because it depends on session_.
   stats_.reset(nullptr);
+  stats_collector_->WaitForPendingRequest();

[hta-webrtc, 2016/12/16 14:05:31]

Doing waiting in a destructor makes me itchy. The destructor seems to be marked
"protected" in the .h files - is it possible to do the waiting in the function
that calls the destructor instead, and just assert that there are no pending
requests when you get to the destructor level?

There's another wait below (the Invoke()), where the same comments apply, so you
wouldn't make the destructor more irritating to me than it already is, but it's
nice to not cause excessive itches.

[hbos, 2016/12/16 14:34:52]

I'm afraid not, PeerConnectionInterface is reference counted, the only thing we
can be sure of is that we're on the signaling thread.

[hta-webrtc, 2016/12/17 19:51:30]

OK, the only thing that calls the destructor is the subclass constructed by
RefCounted<PeerConnection>..... but you have no real control over when the
refcount hits zero. Then this makes sense.

+  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...