Assertion failures with transport-cc enabled
Categories
(Core :: WebRTC: Audio/Video, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox75 | --- | unaffected |
firefox76 | --- | wontfix |
firefox77 | --- | fixed |
People
(Reporter: dminor, Assigned: dminor)
References
(Depends on 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(1 file)
This is happening for me consistently on meet.jit.si and whereby.com, if I turn on the media.navigator.video.use_transport_cc pref with an opt+debug build:
#
# Fatal error in /home/dminor/src/firefox/media/webrtc/trunk/webrtc/audio/audio_send_stream.cc, line 389
# last system error: 0
# Check failed: worker_thread_checker_.CalledOnValidThread()
#
#
Redirecting call to abort() to mozalloc_abort
Hit MOZ_CRASH() at /home/dminor/src/firefox/memory/mozalloc/mozalloc_abort.cpp:33
:jryans, do you have some time to look into this, or would it be better if someone from the Mozilla WebRTC team tracks this one down?
Comment 1•4 years ago
|
||
This is definitely something the team should look into. At a glance, I'm not seeing anything in that patch that causes new calls into webrtc.org, so this is likely a pre-existing problem. Some quick scanning over searchfox hints that this code has threading expectations that the rest of the RTP/RTCP code does not have.
Happy to help here if I can, but I don't have any context on the multi-threading expectations in this area, so would likely be more efficient for the team to take this.
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
We're (eventually) calling into AudioSendStream::OnPacketFeedbackVector after a packet is delivered on the VideoConduit, which happens on the sts thread, but AudioSendStream is constructed on the main thread. This trips up the worker_thread_checker_.CalledOnValidThread() check. There is already some locking in OnPacketFeedbackVector, so hopefully it will be safe to just disable the assertion in this case.
Assignee | ||
Comment 4•4 years ago
|
||
With transport-cc enabled, we get feedback calls into AudioSendStream occuring
on the sts thread. Since AudioSendStream is constructed on the main thread,
this trips up the worker_thread_checker_ checks. The functions that are called
end up doing their work using AudioCodingModuleImpl::ModifyEncoder, which
takes a lock, so it should be safe to remove these assertions.
We've had to do similar things to ChannelProxy in the past to get stats
working from the sts thread. ChannelProxy has been removed upstream, but we
should consider changing our use of AudioSendStream with the next libwebrtc
update so that is always called from the same thread.
Pushed by dminor@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f024099de1ee Disable some threading asserts in AudioSendStream and ChannelProxy; r=bwc
Comment 6•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Updated•4 years ago
|
Description
•