1066036 - OOM causes a browser crash in decodeAudioData.

Status: RESOLVED INVALID

(Core :: Web Audio, defect, P5)

Description

[Jukka Jylänki]

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 https://crash-stats.mozilla.com/report/index/1c439e58-9635-497e-964c-c25d92140911.

Looking at the code at http://hg.mozilla.org/mozilla-central/annotate/152ef25e89ae/content/media/AudioCompactor.h#l44 , it unconditionally calls 'new AudioDataValue[samples]' without being prepared for an OOM situation (?).

Comment 1

[Benjamin Smedberg]

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?

Comment 2

[Paul Adenot (:padenot)]

CCing Ben Kelly, who wrote this. Ben, do you know why we are OOMing here ?

Comment 3

[Jukka Jylänki]

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.

Comment 4

[Benjamin Smedberg]

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]

Comment 5

[Paul Adenot (:padenot)]

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.

http://hg.mozilla.org/mozilla-central/annotate/152ef25e89ae/content/media/webaudio/MediaBufferDecoder.cpp#l309

Comment 6

[Petruta Horea [:phorea], Desktop Test Engineering]

Ubuntu 14.04 32-bit   Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0

Encountered the crash https://crash-stats.mozilla.com/report/index/bp-eea8d3f5-060a-4e7d-84df-557192141028 using Firefox 34 beta 4 while playing a youtube video in one tab and trying to play several videos from vimeo.com in another tab.

I couldn't reproduce the bug afterwards, but please let me know if I can help with anything.

Comment 7

[Paul Adenot (:padenot)]

This should be fixed in the underlying decoders.

Comment 8

[Bulk Bug Changes for mreavy's org]

Mass change P4->P5 to align with new Mozilla triage process.

Comment 9

[Paul Adenot (:padenot)]

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.