Closed
Bug 456648
Opened 16 years ago
Closed 15 years ago
Changing Ogg <video> src attribute while playing unreliable [@ nsOggDecoder::LoadFirstFrame]
Categories
(Core :: Audio/Video, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: cpearce, Assigned: cajbir)
References
()
Details
(Keywords: crash)
Crash Data
Attachments
(1 file, 2 obsolete files)
8.67 KB,
patch
|
Details | Diff | Splinter Review |
When an Ogg <video> is playing, if you change the src attribute to another Ogg video, it doesn't change reliably. Sometimes it works, but sometimes you get a crash, and sometimes the only thing that happens is the video playback halts (without actually being in a paused state). If you try to change the src attribute several times in quick succession, it often crashes. See URL for a testcase, and STR for a crash. Stack trace of that crash: gklayout.dll!nsOggDecoder::LoadFirstFrame() Line 691 + 0x20 bytes C++ gklayout.dll!nsRunnableMethod<nsOggDecoder>::Run() Line 265 C++ xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0610f9a0) Line 511 C++ xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x07bfb2b0, int mayWait=1) Line 227 + 0x16 bytes C++ xpcom_core.dll!nsThread::ThreadFunc(void * arg=0x07bfb2b0) Line 254 + 0xb bytes C++ nspr4.dll!_PR_NativeRunThread(void * arg=0x07bc1ea0) Line 436 + 0xf bytes C nspr4.dll!pr_root(void * arg=0x07bc1ea0) Line 122 + 0xf bytes C msvcr80d.dll!71b148d1() It's a null COMPtr dereference on nsOggDecoder::mPresentationThread. It's also easy enough to reproduce a crash when setting the src attribute to "".
Severity: normal → critical
Keywords: crash
Summary: Changing Ogg <video> src attribute while playing unreliable → Changing Ogg <video> src attribute while playing unreliable [@ nsOggDecoder::LoadFirstFrame]
Comment 1•16 years ago
|
||
Confirmed with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080923020412 Minefield/3.1b1pre * First time no stack trace. * Second time no crashreporter; terminal: pure virtual method called terminate called without an active exception terminate called recursively ./run-mozilla.sh: line 131: 11797 Aborted "$prog" ${1+"$@"} Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080924020520 Minefield/3.1b1pre Mplayer running at the same time. http://crash-stats.mozilla.com/report/index/a2b61bd4-8a55-11dd-a26c-001a4bd43ed6?p=1 OS Version 0.0.0 Linux 2.6.26-1-686 #1 SMP Wed Sep 10 16:46:13 UTC 2008 i686 GNU/Linux CPU x86 CPU Info AuthenticAMD family 1 model 44 stepping 2 Crash Reason SIGSEGV Crash Address 0xb6a50cd0 0 libasound.so.2.0.0 libasound.so.2.0.0@0x7ccd0 1 libasound.so.2.0.0 libasound.so.2.0.0@0x4307a 2 libasound.so.2.0.0 libasound.so.2.0.0@0x599f9 3 libasound.so.2.0.0 libasound.so.2.0.0@0x4307a 4 libasound.so.2.0.0 libasound.so.2.0.0@0x64c58 5 libasound.so.2.0.0 libasound.so.2.0.0@0x6544b 6 libasound.so.2.0.0 libasound.so.2.0.0@0x45a45 7 libasound.so.2.0.0 libasound.so.2.0.0@0x4b3dc 8 libasound.so.2.0.0 libasound.so.2.0.0@0x4b58e 9 libasound.so.2.0.0 libasound.so.2.0.0@0x4b6f0 10 libasound.so.2.0.0 libasound.so.2.0.0@0x56f10 11 libasound.so.2.0.0 libasound.so.2.0.0@0x46143 12 libxul.so audio_callback media/liboggplay_audio/sydney_audio_alsa.c:428 13 libpthread-2.7.so libpthread-2.7.so@0x64bf
OS: Windows Vista → All
Assignee | ||
Comment 2•16 years ago
|
||
First cut at a fix. Tests to follow. Requires patch from bug 449159.
Assignee: nobody → chris.double
Assignee | ||
Comment 3•16 years ago
|
||
Updated to trunk. I'll write some tests before seeking review.
Attachment #340278 -
Attachment is obsolete: true
Assignee | ||
Comment 4•16 years ago
|
||
Attachment #344269 -
Attachment is obsolete: true
Attachment #344396 -
Flags: superreview?(roc)
Attachment #344396 -
Flags: review?(roc)
I think we need to do something after the "abort" has been dispatched, in case dispatching that event changes the state of the video element so that we should no longer proceed with the Load. Like what should happen if someone does "load" and the "abort" event handler itself does a load? At least we should check mBegun again, I guess. Should the "abort" event even be dispatched synchronously? And what state should the element be in when "abort" is fired? Right now we've set the error object but the decoder is still there. Probably should add a test for evil "abort" behaviour, as well.
Assignee | ||
Updated•15 years ago
|
Attachment #344396 -
Flags: superreview?(roc)
Attachment #344396 -
Flags: review?(roc)
I think this all got fixed when we implemented the updated spec for dynamic src/source changes.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 7•13 years ago
|
||
Verified, works with Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110115 Firefox/4.0b10pre
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Crash Signature: [@ nsOggDecoder::LoadFirstFrame]
You need to log in
before you can comment on or make changes to this bug.
Description
•