Out of memory crash with slow audio stream

VERIFIED FIXED

Status

()

Core
Audio/Video
VERIFIED FIXED
7 years ago
7 years ago

People

(Reporter: jorge alves, Assigned: kinetik)

Tracking

({hang})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

20.87 KB, application/x-zip-compressed
Details
1.98 KB, patch
roc
: review+
Details | Diff | Splinter Review
(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101223 Firefox/4.0b9pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101223 Firefox/4.0b9pre

In the provided URL, after moving the audio cursor to an earlier position, the browsers enters an infinite loop increasingly consuming memory until the system limit is reached (4gb in my case).

Note: the crash reporter does not appear.

Reproducible: Always

Steps to Reproduce:
1. go to the URL provided
2. look for the first audio stream widget and press play
3. move the audio cursor to an earlier position in time
4. repeat (3) until the browser hangs
Actual Results:  
The browser hangs until all memory is consumed. Then the process crashes.

Expected Results:  
The audio stream changes the position and buffers as needed.

At the current moment the streams are buffering slowly and this may be an important contributing factor.
(Reporter)

Comment 1

7 years ago
Also happens with 3.6.14pre

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.14pre) Gecko/20101223 Namoroka/3.6.14pre
(Reporter)

Comment 2

7 years ago
The original URL seems to have enough bandwidth to serve the smaller files now.
This makes the original steps difficult to reproduce. :/

Updated STR:
1. go to the URL provided
2. look for audio stream with title "CELT, AAC and Vorbis @ 64kbps 48kHz stereo"
3. select "uncompressed" beneath the widget
4. click play
5. move the audio cursor to an earlier position in time, just before the buffer limit
6. repeat (3) until the browser hangs - It normally happens the first time

And I just got a crash report from namoroka:
http://crash-stats.mozilla.com/report/index/bp-6fe8f5b1-83dc-4d9d-9af0-54a2f2101223

..but it's having trouble retrieving it:

Oh Noes!
This archived report could not be located.

Comment 3

7 years ago
Created attachment 499638 [details]
WinDbg log ()

I can reproduce STR in comment #2 on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101222 Firefox/4.0b9pre ID:20101222030351 and Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.14pre) Gecko/20101215 Firefox/3.6.14pre ID:20101215033249.

Comment 4

7 years ago
Comment on attachment 499638 [details]
WinDbg log ()

alice: please install and use the *32*bit version of windbg.
Attachment #499638 - Attachment is obsolete: true

Comment 5

7 years ago
Created attachment 499649 [details]
WinDbg log

Updated

7 years ago
Keywords: hang
Hardware: x86_64 → x86
(Assignee)

Comment 6

7 years ago
I can reproduce this with a tip build of the 1.9.2 branch.  I can't reproduce it with mozilla-central, but the same bug appears to exist there.  In debug builds of either branch, the state machine validation fails and aborts the program.  In non-debug builds, it becomes stuck in BUFFERING state and fires events at the main thread continuously, possibling resulting in an OOM crash.

The state machine validation is reporting a violation when transitioning from SEEKING to BUFFERING.  This transition makes no sense, since the SEEKING state does not recompute the buffering parameters before entering the BUFFERING state.  This results in mState and mNextState both being set to BUFFERING.  When the BUFFERING state runs, it detects that sufficient data is available, so fires an event and attempts to enter mNextState.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 7

7 years ago
Created attachment 501240 [details] [diff] [review]
patch v0
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Attachment #501240 - Flags: review?(roc)
Attachment #501240 - Flags: approval2.0?
(Reporter)

Comment 8

7 years ago
Your patch fixes it for me in a trunk build.
Attachment #501240 - Flags: review?(roc)
Attachment #501240 - Flags: review+
Attachment #501240 - Flags: approval2.0?
Attachment #501240 - Flags: approval2.0+
(Reporter)

Comment 9

7 years ago
Is there anything I can do to help push this patch? It's surprisingly easy to crash the browser when trying to seek any stream that is still loading. 

Just tried playing the <audio> Test 2.0Mb in the following page:
http://www.jplayer.org/HTML5.Audio.Support/

While the stream loads, seeking into positions close to the buffer limit will trigger this.
(Assignee)

Comment 10

7 years ago
It's ready to land and I haven't forgotten about it, I'll try to get it checked in soon.
(Assignee)

Comment 11

7 years ago
http://hg.mozilla.org/mozilla-central/rev/d00044f2dc80
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Verified using Minefield nightly from 2011-01-22.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.