Closed
Bug 621257
Opened 14 years ago
Closed 14 years ago
Out of memory crash with slow audio stream
Categories
(Core :: Audio/Video, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jag.alves, Assigned: kinetik)
References
()
Details
(Keywords: hang)
Attachments
(2 files, 1 obsolete file)
20.87 KB,
application/x-zip-compressed
|
Details | |
1.98 KB,
patch
|
roc
:
review+
roc
:
approval2.0+
|
Details | Diff | Splinter Review |
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•14 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•14 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•14 years ago
|
||
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 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•14 years ago
|
||
Assignee | ||
Comment 6•14 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•14 years ago
|
||
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Attachment #501240 -
Flags: review?(roc)
Attachment #501240 -
Flags: approval2.0?
Reporter | ||
Comment 8•14 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•14 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•14 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•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 12•14 years ago
|
||
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.
Description
•