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 (?).
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?
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.
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  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
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.
This should be fixed in the underlying decoders.
Component: Web Audio → Video/Audio
Component: Audio/Video → Audio/Video: Playback
Severity: critical → normal
Priority: -- → P4
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5
You need to log in before you can comment on or make changes to this bug.