Deadlock between webrtc::ProcessThreadImpl and webrtc::ViEChannelManager

NEW
Unassigned

Status

()

Core
WebRTC
P5
normal
Rank:
45
3 years ago
3 months ago

People

(Reporter: pehrsons, Unassigned)

Tracking

Trunk
All
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8533119 [details]
Full stack traces for both sides of the deadlock

I have a patch in the works on bug 1073406 that adds an extra DOMMediaStream to a media element for playback. Somehow that triggers this bug on e10s builds.

See here (M-e10s-3):
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=e1e1feb3f9d0

It's not 100% but close, and since several tests exercise this code there's virtually a 100% failure rate on try.

Here are relevant parts of the deadlock. See attachment for full stack traces.

##### Main thread ######
#3  0x00007ffff23fb218 in webrtc::ProcessThreadImpl::DeRegisterModule (this=0x7fffcfbb6d00, module=0x7fffb05f8750)
    at /home/pehrsons/mozilla-central/media/webrtc/trunk/webrtc/modules/utility/source/process_thread_impl.cc:116
#4  0x00007ffff238ccda in webrtc::ViEChannel::SetVoiceChannel (this=0x7fffb05f8000, ve_channel_id=-1, ve_sync_interface=0x0)
    at /home/pehrsons/mozilla-central/media/webrtc/trunk/webrtc/video_engine/vie_channel.cc:2010
#5  0x00007ffff238d36d in webrtc::ViEChannelManager::DisconnectVoiceChannel (this=<optimised out>, channel_id=0)
    at /home/pehrsons/mozilla-central/media/webrtc/trunk/webrtc/video_engine/vie_channel_manager.cc:358

##### ProcessThread #####
#3  0x00007ffff2396413 in webrtc::ViEChannelManager::ViEEncoderPtr (this=0x7fffca899ac0, video_channel_id=0)
    at /home/pehrsons/mozilla-central/media/webrtc/trunk/webrtc/video_engine/vie_channel_manager.cc:464
#4  0x00007ffff2396f04 in Encoder (vie_channel_id=0, this=0x7fffafcfece0)
    at /home/pehrsons/mozilla-central/media/webrtc/trunk/webrtc/video_engine/vie_channel_manager.cc:552
#5  webrtc::ViECodecImpl::GetSendCodecStatistics (this=0x7fffd2aff670, video_channel=0, key_frames=@0x7fffafcfed38: 3506771664, delta_frames=
    @0x7fffafcfed3c: 32767) at /home/pehrsons/mozilla-central/media/webrtc/trunk/webrtc/video_engine/vie_codec_impl.cc:423
#6  0x00007ffff1060340 in mozilla::VideoCodecStatistics::OutgoingRate (this=<optimised out>, video_channel=<optimised out>, framerate=0, bitrate=0)
    at /home/pehrsons/mozilla-central/media/webrtc/signaling/src/media-conduit/CodecStatistics.cpp:53
#7  0x00007ffff2389443 in webrtc::ViEEncoder::SendStatistics (this=<optimised out>, bit_rate=0, frame_rate=0)
    at /home/pehrsons/mozilla-central/media/webrtc/trunk/webrtc/video_engine/vie_encoder.cc:947
#8  0x00007ffff23841bc in webrtc::vcm::VideoSender::Process (this=0x7fffb5fba800)
    at /home/pehrsons/mozilla-central/media/webrtc/trunk/webrtc/modules/video_coding/main/source/video_sender.cc:97
#9  0x00007ffff23853d5 in webrtc::(anonymous namespace)::VideoCodingModuleImpl::Process (this=0x7fffcbea32c0)
    at /home/pehrsons/mozilla-central/media/webrtc/trunk/webrtc/modules/video_coding/main/source/video_coding_impl.cc:104
#10 0x00007ffff23fb95b in webrtc::ProcessThreadImpl::Process (this=0x7fffcfbb6d00)
    at /home/pehrsons/mozilla-central/media/webrtc/trunk/webrtc/modules/utility/source/process_thread_impl.cc:172
(Reporter)

Updated

3 years ago
Blocks: 1073406
(Reporter)

Comment 1

3 years ago
I'm kinda new to e10s but it does seem that I reproduced it without e10s enabled, so that would make it linux specific rather than e10s specific.
OS: All → Linux
(Reporter)

Comment 2

3 years ago
Looks like it's completely inside gips code. Randell, have you seen this one before?
Flags: needinfo?(rjesup)
No, I haven't seen it. It'd be worth checking if it happens with the Webrtc.org/40 drop or if the locking code there has changed.  See http://hg.mozilla.org/users/rjesup_wgate.com/webrtc_40 for the current non-working patchqueue for importing 40 (ignore errors when qpushing the queue)
Flags: needinfo?(rjesup)
(Reporter)

Comment 4

3 years ago
I did look through some relevant points in the paths for the deadlock in the webrtc.org trunk. They hadn't changed.

Also, the deadlock is gone with the patches for bug 1109405. So looks like this is a potential deadlock, but in practice we won't hit it. I'll be happy spending my time somewhere else.
backlog: --- → webRTC+
Rank: 45
Priority: -- → P4
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5
You need to log in before you can comment on or make changes to this bug.