Closed Bug 923992 Opened 6 years ago Closed 6 years ago

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*) ]

Categories

(Core :: Audio/Video, defect, critical)

x86
Windows 8
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla28

People

(Reporter: fehe, Assigned: kinetik)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(3 files)

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
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*) ]
Keywords: crash
Bug 866675 seems a most likely culprit.
Blocks: 866675
Keywords: regression
Assignee: nobody → paul
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.
Assignee: paul → kinetik
Attachment #8339026 - Flags: review?(paul)
Comment on attachment 8339026 [details] [diff] [review]
bug923992_v0.patch

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

Makes sense.
Attachment #8339026 - Flags: review?(paul) → review+
(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
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
https://hg.mozilla.org/mozilla-central/rev/41c241079f25
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
I can confirm this is fixed.  Tested with holly nightly cset: http://hg.mozilla.org/projects/holly/rev/3831bd01eb41

Thanks
Status: RESOLVED → VERIFIED
Thanks for the confirmation!
You need to log in before you can comment on or make changes to this bug.