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)

x86
All
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: cpearce, Assigned: cajbir)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(1 file, 2 obsolete files)

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]
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
Attached patch Handle src changing (obsolete) — Splinter Review
First cut at a fix. Tests to follow. Requires patch from bug 449159.
Assignee: nobody → chris.double
Depends on: 449159
Attached patch Updated to trunk (obsolete) — Splinter Review
Updated to trunk. I'll write some tests before seeking review.
Attachment #340278 - Attachment is obsolete: true
Attached patch Include testSplinter Review
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.
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
Verified, works with Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110115 Firefox/4.0b10pre
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsOggDecoder::LoadFirstFrame]
You need to log in before you can comment on or make changes to this bug.