1507216 - Crash in mozalloc_abort | abort | webrtc::internal::Call::~Call

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P2)

Description

[Marcia Knous [:marcia]]

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

=============================================================

Comment 1

[Dan Minor [:dminor]]

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

Comment 2

[Dan Minor [:dminor]]

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

Comment 3

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=01a52a9c4de7e2d2e1566628ba9eda61dc6fdd30

Comment 4

[Byron Campen [:bwc]]

I tripped over this while working on bug 1507861.

Comment 5

[Byron Campen [:bwc]]

Attachment: Bug 1507216: Make sure AudioConduit doesn't re-create the recv stream without de-registering the old one.

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.

Comment 6

[Byron Campen [:bwc]]

Nico, can you weigh in on this?

https://phabricator.services.mozilla.com/D12936#inline-66160

Comment 7

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=352a641d9e1d66e9507386b8cff969c84e982384

Comment 8

[Nico Grunbaum [:ng, @chew:mozilla.org]]

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

Comment 9

[Pulsebot]

Pushed by [e-mail]:
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

Comment 10

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/26598a115edd