Closed
Bug 1303083
Opened 8 years ago
Closed 8 years ago
Crash in MOZ_RELEASE_ASSERT(mOutputRate) (output rate can't be 0.)
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
RESOLVED
FIXED
mozilla51
Tracking | Status | |
---|---|---|
firefox51 | --- | fixed |
People
(Reporter: mccr8, Assigned: kinetik)
References
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
4.16 KB,
patch
|
padenot
:
review+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is
report bp-97be53d8-33eb-4b7b-a5a8-057ed2160915.
=============================================================
This looks like a new crash in the September 14 build.
Based on the crash stack, maybe this is a regression from bug 1299072? Could you take a look at this, jya? Thanks.
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(jyavenard)
Keywords: regression
Comment 1•8 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #0)
> This bug was filed from the Socorro interface and is
> report bp-97be53d8-33eb-4b7b-a5a8-057ed2160915.
> =============================================================
>
> This looks like a new crash in the September 14 build.
>
> Based on the crash stack, maybe this is a regression from bug 1299072? Could
> you take a look at this, jya? Thanks.
What in the crash stack indicates that it's a regression caused by bug 1299072? The crash is in VideoSink/audioSink..
mOutputRate isn't controlled by the media decoding stack, it comes from either what the hardware reports via AudioStream::GetPreferredRate(); or if they have set a hidden pref "media.resampling.rate".
https://hg.mozilla.org/mozilla-central/annotate/29af101880db/dom/media/mediasink/DecodedAudioDataSink.cpp#l70
Now either cubeb is returning a preferred sampling rate of 0 or someone media.resampling.rate was set to 0 (we haven't documented that pref anywhere, and it won't appear in about:config either)
in any case, it can't be a regression introduced by bug 1299072
If it's a used who set the pref to 0, maybe we should add a safeguard there and prevent 0 to be set.
Flags: needinfo?(jyavenard) → needinfo?(kinetik)
Reporter | ||
Comment 2•8 years ago
|
||
Sorry, I didn't look at it closely enough.
There are 30 crashes across 11 install times, so it isn't just one user who set a pref. (Well, I guess somebody could have reinstalled repeatedly.)
Comment 3•8 years ago
|
||
there was a cubeb update on that day...
Assignee | ||
Comment 4•8 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #3)
> there was a cubeb update on that day...
Yeah, likely related. That change stopped us from using the WinMM backend when there's no audio output devices available.
What's probably happening is that we have configurations with no audio, and CubebUtils::InitPreferredSampleRate isn't handling the case where it gets a null context.
Assignee | ||
Comment 5•8 years ago
|
||
Roll InitPreferredSampleRate into PreferredSampleRate since every caller is calling both of them together, and let PreferredSampleRate handle errors from InitPreferredSampleRate by returning a default sample rate while allowing a later call (e.g. when cubeb_init later succeeds) to get the real preferred sample rate.
Also remove the Error state from CubebState added in bug 1300446, since we want to let GetCubebContext{,Unlocked}() to try again later if cubeb_init fails.
Attachment #8791864 -
Flags: review?(padenot)
Updated•8 years ago
|
Attachment #8791864 -
Flags: review?(padenot) → review+
Pushed by mgregan@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/520980c5d845
Make CubebUtils::PreferredSampleRate handle InitPreferredSampleRate failures. r=padenot
Comment 7•8 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in
before you can comment on or make changes to this bug.
Description
•