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

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.

Looks like it's completely inside gips code. Randell, have you seen this one before?

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)

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.

Mass change P4->P5 to align with new Mozilla triage process.