Closed Bug 1414632 Opened 2 years ago Closed 2 years ago
Crash in webrtc::Merge::Signal
This bug was filed from the Socorro interface and is report bp-1b6b5cfb-6b6b-4753-9d6a-42fff0171102. ============================================================= This is topcrash #17 in the Windows nightly 20171102100041. It is reported as an integer division by zero.
We divide by mod_input_length in the line just above the one causing the crash , perhaps that calculation is being inlined on line 219 causing the error to be reported there. If mod_input_length is zero, then it looks like either the input buffer length is zero, or the input sampling frequency is zero.  https://hg.mozilla.org/mozilla-central/annotate/515407ebfa14/media/webrtc/trunk/webrtc/modules/audio_coding/neteq/merge.cc#l218
First crash is in the 10/30 Nightly. All earlier crashes (2) are a different issue with (probably) negative energy. So we should look at what's new in 10/30. All are windows
Also: since this is a new regression, I'm moving this to p1 - we shouldn't ship new regressions we find during nightly.
Rank: 15 → 8
Priority: P2 → P1
Dan, since all P1's need an owner and you took an initial look can I ask you to continue to investigate taking Randell's observations into account? Let me know if you want me to find another owner.
Assignee: nobody → dminor
Just a thought: if the code hasn't changed in the date range have we already switched to a new Visual Studio version (I remember seeing something regarding VS 2017 on a mailing list) which compiles the code differently?
Sure, I'll have a look.
Attachment #8926540 - Flags: review?(rjesup) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/e47ee65540ba Prevent division by zero in webrtc::Merge::SignalScaling; r=jesup
We should upstream this fix.
You need to log in before you can comment on or make changes to this bug.