Closed Bug 1674597 Opened 3 years ago Closed 3 years ago

Crash in [@ mozilla::MozPromise<T>::Private::Reject<T>] called from AudioSink::Init

Categories

(Core :: Audio/Video: Playback, defect, P3)

defect

Tracking

()

RESOLVED FIXED
84 Branch
Tracking Status
firefox-esr78 --- wontfix
firefox82 --- wontfix
firefox83 --- wontfix
firefox84 --- fixed

People

(Reporter: aryx, Assigned: alwu)

References

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

Has hit Nightly and DevEdition (?) builds rarely over the last cycles, got crashes on 3 different installations today.

Crash report: https://crash-stats.mozilla.org/report/index/6c44301f-e00c-4ca7-b900-2ebe80201031

Reason: SIGSEGV /SEGV_MAPERR

Top 10 frames of crashing thread:

0 libxul.so void mozilla::MozPromise<bool, nsresult, false>::Private::Reject<nsresult&> xpcom/threads/MozPromise.h:1145
1 libxul.so mozilla::AudioSink::Init dom/media/mediasink/AudioSink.cpp:97
2 libxul.so mozilla::AudioSinkWrapper::Start dom/media/mediasink/AudioSinkWrapper.cpp:160
3 libxul.so mozilla::VideoSink::Start dom/media/mediasink/VideoSink.cpp:218
4 libxul.so mozilla::MediaDecoderStateMachine::StartMediaSink dom/media/MediaDecoderStateMachine.cpp:3364
5 libxul.so mozilla::MediaDecoderStateMachine::MaybeStartPlayback dom/media/MediaDecoderStateMachine.cpp:2966
6 libxul.so mozilla::MediaDecoderStateMachine::DecodingState::Step dom/media/MediaDecoderStateMachine.cpp:2404
7 libxul.so mozilla::MediaDecoderStateMachine::RunStateMachine dom/media/MediaDecoderStateMachine.cpp:3526
8 libxul.so mozilla::detail::RunnableMethodImpl<mozilla::MediaDecoderStateMachine*, void  xpcom/threads/nsThreadUtils.h:1240
9 libxul.so mozilla::AutoTaskDispatcher::TaskGroupRunnable::Run xpcom/threads/TaskDispatcher.h:228

This crash happened inside the promise, indicating that it has been destroyed.

However, we create a promise in [1], so when we call [2], the promise should still exist. And I didn't see any possibility to destroy the promise happening between [1] and [2]...

Paul, do you have any thought about this crash? are you aware any possible recent change which might cause this?
Thank you.

[1] https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/dom/media/mediasink/AudioSink.cpp#94
[2] https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/dom/media/mediasink/AudioSink.cpp#97

Severity: -- → S1
Flags: needinfo?(padenot)
Priority: -- → P3

Low volume crash but might be peaking on Nightly. Downgrading to S2.

Severity: S1 → S2

I assume the cubeb state callback can be called with DRAINED if somehow the stream to play is very short. At this point mEndedPromise would have been resolved, possibly causing this ?

Does this make sense, maybe with a second look ? A fix would be to check the promise state, as it's possible to have a stream that DRAINs on its first audio callback (imagine a very very short audio file).

Flags: needinfo?(padenot) → needinfo?(alwu)

Sounds reasonable, but that is a bad pattern because that ideally we are not expecting to resolve/reject the promise inside InitializeAudioStream(). Let me think how we can improve this. Thank you.

Assignee: nobody → alwu
Flags: needinfo?(alwu)

Added multiple crash signatures for the same stack. These either come from packaged builds from different Linux distros (so the debug information is slightly different) or different Windows versions where the symbols coming from the Microsoft library have slight differences.

Crash Signature: [@ mozilla::MozPromise<T>::Private::Reject<T>] → [@ libpthread.so.0@0x9c30] [@ mozilla::MozPromise<T>::Private::Reject<T>] [@ __pthread_mutex_lock | mozilla::detail::MutexImpl::lock | mozilla::MozPromise<T>::Private::Reject<T>] [@ __pthread_mutex_lock | <name omitted> | mozilla::AudioSink::Init] [@ …

Top crash signature on Linux for the 11/5 Nightlies, with about 34% of all crashes (31 crashes).

quick update: I've been working on it, will update my patch today if no error is discovered.

Audio stream is the class which really know about whether the audio playback is completed or not. So it makes more sense to let it return and manage the promise for playback end, not audio sink.

Pushed by alwu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5c171eb1f34c
part1 : let audio stream to manage the ended promise for playback. r=padenot
https://hg.mozilla.org/integration/autoland/rev/16607dd924c5
part2 : refactor `AudioSinkWrapper::Start` in order to remove unnecessary indentation. r=padenot
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch

Some singatures are actually related with bug 1675061, not this one.

Crash Signature: [@ libpthread.so.0@0x9c30] [@ mozilla::MozPromise<T>::Private::Reject<T>] [@ __pthread_mutex_lock | mozilla::detail::MutexImpl::lock | mozilla::MozPromise<T>::Private::Reject<T>] [@ __pthread_mutex_lock | <name omitted> | mozilla::AudioSink::Init] [@ … → [@ libpthread.so.0@0x9c30] [@ mozilla::MozPromise<T>::Private::Reject<T>] [@ __pthread_mutex_lock | mozilla::detail::MutexImpl::lock | mozilla::MozPromise<T>::Private::Reject<T>] [@ __pthread_mutex_lock | <name omitted> | mozilla::AudioSink::Init]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: