Closed Bug 1246051 Opened 8 years ago Closed 8 years ago

MediaQueue<T>::Peek/PeekFront are not thread-safe

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox49 --- fixed

People

(Reporter: jwwang, Assigned: jwwang)

References

Details

Attachments

(1 file)

Considering the following code:
RefPtr<T> foo = queue.PeekFront();

It is possible for the foo constructor to receive a dangling pointer if queue.Reset() is called on another thread in the mean time.
the only place doing so is MediaDecoderStateMachine::SeekCompleted()

But isn't queue.Reset() only ever called on the MDSM thread?
We either need to document this pitfall or make it thread-safe to be usable outside the context of MDSM.
(In reply to Jean-Yves Avenard [:jya] from comment #1)
> the only place doing so is MediaDecoderStateMachine::SeekCompleted()
> 
> But isn't queue.Reset() only ever called on the MDSM thread?

https://hg.mozilla.org/mozilla-central/file/584870f1cbc5d060a57e147ce249f736956e2b62/dom/media/mediasink/DecodedAudioDataSink.cpp#l221

We have such usages in DecodedAudioDataSink::PopFrames() which is called from libcubeb callback threads.
I believe this issue is one of the reason for crashes seen in the Android emulator as seen in bug 1264199
See Also: → 1265932
Blocks: 1264199
Attachment #8744793 - Flags: review?(gsquelart) → review+
Comment on attachment 8744793 [details]
MozReview Request: Bug 1246051 - have MediaQueue<T>::Peek/PeekFront return a RefPtr<> to avoid dangling pointers per comment 0. r=gerald.

https://reviewboard.mozilla.org/r/48675/#review45437
Thanks for the review!
Assignee: nobody → jwwang
https://hg.mozilla.org/mozilla-central/rev/2dbdefa829d1
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: