This bug was filed from the Socorro interface and is report bp-63ec910e-7a8f-4655-93ee-00df90181112. ============================================================= Seen while looking at nightly crash stats: https://bit.ly/2T6XKrD. Crashes appear to have started using 20181111220121 and are 10.14 only. Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e9ff3fec51d3de454f607b69b4acddc2a81409c1&tochange=b0abee059ce6ac62f99eb7f021562a6d3e7587cf Top 10 frames of crashing thread: 0 libmozglue.dylib mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:35 1 libmozglue.dylib abort memory/mozalloc/mozalloc_abort.cpp:82 2 XUL rtc::FatalMessage::~FatalMessage media/webrtc/trunk/webrtc/rtc_base/checks.cc:69 3 XUL rtc::FatalMessage::~FatalMessage media/webrtc/trunk/webrtc/rtc_base/checks.cc:63 4 XUL webrtc::internal::Call::~Call clang/include/c++/v1/ostream:1002 5 XUL <name omitted> media/webrtc/trunk/webrtc/call/call.cc:479 6 XUL mozilla::WebRtcCallWrapper::~WebRtcCallWrapper mfbt/UniquePtr.h:528 7 XUL mozilla::WebRtcCallWrapper::~WebRtcCallWrapper media/webrtc/signaling/src/media-conduit/MediaConduitInterface.h:298 8 XUL mozilla::TransceiverImpl::~TransceiverImpl mfbt/RefCounted.h:215 9 XUL mozilla::TransceiverImpl::~TransceiverImpl media/webrtc/signaling/src/peerconnection/TransceiverImpl.cpp:77 =============================================================

Bug 1376873 (the webrtc.org update) landed on the 9th, and added a new check here [1]. If this is a low frequency crash, it's possible it did not show up until the 11th. [1] https://hg.mozilla.org/mozilla-central/annotate/b0abee059ce6ac62f99eb7f021562a6d3e7587cf/media/webrtc/trunk/webrtc/call/call.cc#l485

Looking at [1] we have a crash on Linux on the 9th. I think this is most likely fallout from the webrtc.org update. [1] https://crash-stats.mozilla.com/signature/?signature=mozalloc_abort%20%7C%20abort%20%7C%20webrtc%3A%3Ainternal%3A%3ACall%3A%3A~Call&date=%3E%3D2018-11-08T01%3A44%3A03.000Z&date=%3C2018-11-15T01%3A44%3A03.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1

I tripped over this while working on bug 1507861.

Make a cleaner distinction between having a recv stream that is inactive, and no recv stream at all. Requires some modification to local RTC extension configuration, because of a test-case that assumed StopReceiving/StartReceiving would re-create the recv stream as opposed to simply restarting it.

Nico, can you weigh in on this? https://phabricator.services.mozilla.com/D12936#inline-66160

Copy-pasted from my comment in the review: "After some digging and consulting with Michael, I think that preserving the current behavior (which this code does) and following up in bug 1405495 is the safest course of action here..."

Pushed by bcampen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/26598a115edd Make sure AudioConduit doesn't re-create the recv stream without de-registering the old one. r=dminor