1200272 - Cross-thread access without locking on AudioParam event timeline

Status: RESOLVED INVALID

(Core :: Web Audio, defect)

Description

[Paul Adenot (:padenot)]

Working on bug 1184057, I discovered that we don't lock around mEvents in AudioEventTimeline [0], or message pass, or anything like that.

It's being (at least) mutated on the main thread and audio thread (examples: [1], [2]), and read on the audio thread [3]. 

Either I'm missing something, or I don't know why this works without blowing up at all. This can be pretty high traffic for certain applications.

I'm opening this as a sec bug because I'm pretty sure we can do crazy things.

[0]: https://dxr.mozilla.org/mozilla-central/source/dom/media/webaudio/AudioEventTimeline.h?offset=0#615
[1]: written on the main thread: https://dxr.mozilla.org/mozilla-central/source/dom/media/webaudio/AudioEventTimeline.h?offset=0#594
[2]: written on the audio thread: https://dxr.mozilla.org/mozilla-central/source/dom/media/webaudio/AudioEventTimeline.h?offset=0#615
[3]: read on the audio thread: https://dxr.mozilla.org/mozilla-central/source/dom/media/webaudio/AudioEventTimeline.h?offset=500#292

Comment 1

[Karl Tomlinson (:karlt)]

AudioParamTimeline is intended for single thread usage.
The entire object is copied and passed to the processing thread in AudioNodeStream::SetTimelineParameter().

https://dxr.mozilla.org/mozilla-central/rev/f2518b8a7b97b5bb477e94bc9131584007aac887/dom/media/webaudio/AudioNodeStream.cpp#214

Comment 2

[Paul Adenot (:padenot)]

Glad I missed that. Copying potentially massive nsTArrays full of events is not ideal, though.