Closed Bug 1415749 Opened 8 years ago Closed 8 years ago

Intermittent gtest | application crashed [@ mozalloc_abort(char const*)] after "Fatal error in /builds/worker/workspace/build/src/media/webrtc/trunk/webrtc/modules/rtp_rtcp/source/rtp_sender.cc, line 1026"

Categories

(Core :: WebRTC, defect, P3)

Product:
Core
Component:
WebRTC
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: intermittent-bug-filer, Unassigned)

Details

(Keywords: crash, intermittent-failure)

Crash Data

Related to bug 1407653?
Flags: needinfo?(drno)
This look to me like a race condition in our media pipeline unit tests. Here the outgoing packet gets the SSRC of the RTPSender assigned when the packet gets allocated: https://searchfox.org/mozilla-central/rev/02bc7e2b1bcbab2d7b604ca713b42bcefd47ad2d/media/webrtc/trunk/webrtc/modules/rtp_rtcp/source/rtp_sender_audio.cc#221 And just a couple if lines later inside this function call https://searchfox.org/mozilla-central/rev/02bc7e2b1bcbab2d7b604ca713b42bcefd47ad2d/media/webrtc/trunk/webrtc/modules/rtp_rtcp/source/rtp_sender_audio.cc#250 the assertion tells us that the SSRC of the packet and the sender are no longer the same. It's pretty scary if something changes the SSRC of the RTP sender while we are assembling a packet. But I guess the obvious answer is that this runnable here https://searchfox.org/mozilla-central/rev/02bc7e2b1bcbab2d7b604ca713b42bcefd47ad2d/media/webrtc/signaling/gtest/mediapipeline_unittest.cpp#519 could run at any given time, and maybe it ran this time right in between these two function calls. The only other aspect which concerns me is that the rtp_sender_->AssignSequenceNumber() call here https://searchfox.org/mozilla-central/rev/02bc7e2b1bcbab2d7b604ca713b42bcefd47ad2d/media/webrtc/trunk/webrtc/modules/rtp_rtcp/source/rtp_sender_audio.cc# got added for the 57 merge. Byron: what are your thoughts on this one?
Rank: 25
Flags: needinfo?(drno) → needinfo?(docfaraday)
Priority: P5 → P3
Yeah, I think there's a race here, but I am not sure it is a flaw in the unit test exactly. We always stop transmitting before updating the local SSRC, and there's nothing else we can do to prevent this stale packet from tripping over this check (as far as I can see). I have a feeling that cases where we update the local SSRC in the real world are extremely rare, multiplied by the rarity of people running debug builds, so we don't see this much on crash-stats. I would say this is a bug in webrtc.org.
Flags: needinfo?(docfaraday)
(In reply to Byron Campen [:bwc] from comment #4) > I have a feeling that cases > where we update the local SSRC in the real world are extremely rare, > multiplied by the rarity of people running debug builds, so we don't see > this much on crash-stats. I would say this is a bug in webrtc.org. Just for clarification: this is not only going to crash debug builds. Right now the RTC_DCHECK's in webrtc.org code also get translated into mozassert in release builds.
I was able to find a single crash in the last 6 months with AssignSequenceNumber in the stack: https://crash-stats.mozilla.com/report/index/2ba8b809-fc38-40fb-86fe-d804f0170824 So yeah it's pretty rare.
https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.