Closed Bug 1066036 Opened 10 years ago Closed 5 years ago

OOM causes a browser crash in decodeAudioData.


(Core :: Web Audio, defect, P5)

35 Branch
Windows NT



Tracking Status
firefox34 --- affected
firefox36 --- affected


(Reporter: jujjyl, Unassigned)


(Keywords: crash)

This bug was filed from the Socorro interface and is 
report bp-10cd3d9c-df43-44c7-8528-d0f112140911.

Repeatedly calling decodeAudioData in low memory situations can cause the browser to hard-crash to desktop, instead of gracefully failing the decodeAudioData operation.

Another such report in

Looking at the code at , it unconditionally calls 'new AudioDataValue[samples]' without being prepared for an OOM situation (?).
Not security-sensitive.

The allocation size is 28672, which we consider "small" for the purposes of OOM handling. Is "samples" a user-controlled value which can be any size?
Group: core-security
Flags: needinfo?(jujjyl)
CCing Ben Kelly, who wrote this. Ben, do you know why we are OOMing here ?
I don't know, but I believe so. This is occurring in an application that repeatedly loops to load new audio clips and perform decodeAudioData. I am assuming it is the length of the user-submitted audio clip.
Flags: needinfo?(jujjyl)
If this is a user-controlled buffer size, it should be using fallible malloc and null-checking appropriately. This probably means using

  new (fallible_t()) AudioDataValue[samples]
No, it's not user-controlled. This is crashing in the implementation the mp3 decoder, on a single decoded frame, hence why the alloc that provokes the OOM is so small.

The user-facing API (decodeAudioData) appropriately uses fallible malloc [0] if the result ends up too big, and calls the error callback, as it should.
Ubuntu 14.04 32-bit   Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0

Encountered the crash using Firefox 34 beta 4 while playing a youtube video in one tab and trying to play several videos from in another tab.

I couldn't reproduce the bug afterwards, but please let me know if I can help with anything.
This should be fixed in the underlying decoders.
Component: Web Audio → Video/Audio
Component: Audio/Video → Audio/Video: Playback
Component: Audio/Video: Playback → Web Audio
Severity: critical → normal
Priority: -- → P4
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5

I'm closing this: we're better at handler OOM, and also there is not much we can do here, except having a clear repro case.

Closed: 5 years ago
Resolution: --- → INVALID
Crash Signature: [@ OOM | small]
You need to log in before you can comment on or make changes to this bug.