Unset sinks when deleting CompositeDataChannelTransport.
This fixes a DCHECK during teardown in the case when the primary
DataChannelTranspot (eg. DatagramTransport) is successfully negotiated.
DatagramTransport expects the DataSink to be unset before it's deleted.
This was not caught by existing tests because the fallback transport
(SctpDataChannelTransport) does not have the same DCHECK.
Also adds a regression test for the issue, in which SCTP is available
as a fallback but DataChannelTransport is negotiated successfully.
Bug: webrtc:9719
Change-Id: I414d964d3c85d3d01cdb5e34d6b248659a613c39
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154365
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29292}
diff --git a/pc/composite_data_channel_transport.cc b/pc/composite_data_channel_transport.cc
index 185dd1e..e66febc 100644
--- a/pc/composite_data_channel_transport.cc
+++ b/pc/composite_data_channel_transport.cc
@@ -24,6 +24,12 @@
}
}
+CompositeDataChannelTransport::~CompositeDataChannelTransport() {
+ for (auto transport : transports_) {
+ transport->SetDataSink(nullptr);
+ }
+}
+
void CompositeDataChannelTransport::SetSendTransport(
DataChannelTransportInterface* send_transport) {
if (!absl::c_linear_search(transports_, send_transport)) {