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.
Also happens with 3.6.14pre Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:220.127.116.11pre) Gecko/20101223 Namoroka/3.6.14pre
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.
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:18.104.22.168pre) 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.
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.
Created attachment 501240 [details] [diff] [review] patch v0
Your patch fixes it for me in a trunk build.
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.
It's ready to land and I haven't forgotten about it, I'll try to get it checked in soon.
Verified using Minefield nightly from 2011-01-22.