923992 - crash [@ `anonymous namespace''::wasapi_stream_init(cubeb*, cubeb_stream**, char const*, cubeb_stream_params, unsigned int, long (*)(cubeb_stream*, void*, void*, long), void (*)(cubeb_stream*, void*, cubeb_state), void*) ]

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[IU]

Attachment: firefox-debug_1bcc_2013-09-19_07-25-32-706.txt

I've been getting this crash for a few months now (first encountered July 23).  Here's how I encounter it:

In the morning, I connect to my desktop remotely, using RDP, and update Firefox to the latest nightly and leave Firefox running.  When at home (in the afternoon), without restarting Firefox, I open the Alert Box extension inbox, select the alerts I want the check, and click "Check for Updates."  If an update is found, Alert Box will show a notification and play a bell sound.  It is at the point of playing the sound that Firefox crashes.

However, if I restart Firefox, when I get home, before clicking "Check for Updates," Firefox will not crash when the notification sound plays.

If you install the extension, and go to its settings, you will see that the sound file is an OGG audio file.  I have attached it, for convenience.

I suppose there is a different set of APIs Firefox interfaces to when launched in a Remote Desktop environment vs a normal desktop environment.  However this bug occurs only when at the desktop using a Firefox session that was launched during a Remote Desktop session.  I encounter this with Windows 8 -- not sure if it would be reproducible with other OSes.

My motherboard has an onboard Realtek ALC 892 8-Channel High Definition Audio CODEC.

I have attached a WinDbg log

bp-ff2191b4-f42f-43d2-9d57-fbae92131003

Crash signature: [@ `anonymous namespace''::wasapi_stream_init(cubeb*, cubeb_stream**, char const*, cubeb_stream_params, unsigned int, long (*)(cubeb_stream*, void*, void*, long), void (*)(cubeb_stream*, void*, cubeb_state), void*) ]

Crashing Thread
Frame 	Module 	Signature 	Source
0 	gkmedias.dll 	`anonymous namespace'::wasapi_stream_init(cubeb *,cubeb_stream * *,char const *,cubeb_stream_params,unsigned int,long (*)(cubeb_stream *,void *,void *,long),void (*)(cubeb_stream *,void *,cubeb_state),void *) 	media/libcubeb/src/cubeb_wasapi.cpp
1 	gkmedias.dll 	cubeb_stream_init 	media/libcubeb/src/cubeb.c
2 	xul.dll 	mozilla::BufferedAudioStream::Init(int,int,mozilla::dom::AudioChannelType) 	content/media/AudioStream.cpp
3 	xul.dll 	mozilla::MediaDecoderStateMachine::AudioLoop() 	content/media/MediaDecoderStateMachine.cpp
4 	xul.dll 	nsRunnableMethodImpl<void ( nsCacheService::*)(void),void,1>::Run() 	obj-firefox/dist/include/nsThreadUtils.h
5 	xul.dll 	nsThread::ProcessNextEvent(bool,bool *) 	xpcom/threads/nsThread.cpp
6 	xul.dll 	nsThread::ThreadFunc(void *) 	xpcom/threads/nsThread.cpp
7 	nss3.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c
8 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c
9 	msvcr100.dll 	_callthreadstartex 	f:\\dd\\vctools\\crt_bld\\self_x86\\crt\\src\\threadex.c
10 	msvcr100.dll 	_threadstartex 	f:\\dd\\vctools\\crt_bld\\self_x86\\crt\\src\\threadex.c
11 	kernel32.dll 	BaseThreadInitThunk 	
12 	ntdll.dll 	__RtlUserThreadStart 	
13 	ntdll.dll 	_RtlUserThreadStart

Comment 1

[IU]

Attachment: Audio file played at time of crash

Comment 2

[IU]

Bug 866675 seems a most likely culprit.

Comment 3

[Matthew Gregan [:kinetik]]

A quick guess is that GetMixFormat is returning AUDCLNT_E_DEVICE_INVALIDATED, but since we're not handling errors returned there we try to deref a null mix_format pointer.  Simple fix is to return on error there.  But to make audio actually work, we probably need to call GetDefaultAudioEndpoint and fetch the *current* default rather than the one we cached at the time wasapi_init was called.  I don't see a downside to removing the cached device from the cubeb context and fetching it on each wasapi_stream_init.

Comment 4

[Matthew Gregan [:kinetik]]

Attachment: bug923992_v0.patch

Comment 5

[Paul Adenot (:padenot)]

Comment on attachment 8339026 [details] [diff] [review]
bug923992_v0.patch

Review of attachment 8339026 [details] [diff] [review]:
-----------------------------------------------------------------

Makes sense.

Comment 6

[Matthew Gregan [:kinetik]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/de7d74796ced

Comment 7

[Carsten Book [:Tomcat]]

(In reply to Matthew Gregan [:kinetik] from comment #6)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/de7d74796ced

Hi Matthew,
had to backout this change due to very frequent orange on windows xp with this https://tbpl.mozilla.org/php/getParsedLog.php?id=31207506&tree=Mozilla-Inbound failure

Comment 8

[Matthew Gregan [:kinetik]]

That's pretty strange, this code is only active on Vista upwards.

Oh, except wasapi_init is probably so simple now that it succeeds on XP (thus making it the chosen audio backend) and then fails later on.

Initialize IMMDevice in wasapi_init to make sure WASAPI is actually available: https://tbpl.mozilla.org/?tree=Try&rev=56b136862c64

Comment 9

[Matthew Gregan [:kinetik]]

Looks better: https://tbpl.mozilla.org/?tree=Try&rev=12ae63704dd0

https://hg.mozilla.org/integration/mozilla-inbound/rev/41c241079f25

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/41c241079f25

Comment 11

[IU]

I can confirm this is fixed.  Tested with holly nightly cset: http://hg.mozilla.org/projects/holly/rev/3831bd01eb41

Thanks

Comment 12

[Matthew Gregan [:kinetik]]

Thanks for the confirmation!