1507182 - Crash in shutdownhang | CDeviceEnumerator::DestroyHWndNotificationThread

Status: RESOLVED WORKSFORME

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

Description

[Worcester12345]

This bug was filed from the Socorro interface and is
report bp-e5bfd614-6ebc-4b6a-a33e-0290a0181114.
=============================================================

Top 10 frames of crashing thread:

0 ntdll.dll NtWaitForSingleObject 
1 kernelbase.dll WaitForSingleObjectEx 
2 kernel32.dll WaitForSingleObjectExImplementation 
3 kernel32.dll WaitForSingleObject 
4 mmdevapi.dll CDeviceEnumerator::DestroyHWndNotificationThread 
5 mmdevapi.dll CDeviceEnumerator::SubEnumeratorUnregisterEndpointNotificationCallback 
6 audioses.dll CCrossProcessServerOutputEndpoint::AddTimestampMessage 
7 audioses.dll CAudioSessionControl::FinalRelease 
8 audioses.dll ATL::CComObject<CAudioSessionControl>::~CComObject<CAudioSessionControl> 
9 audioses.dll ATL::CComObject<CAudioSessionControl>::`vector deleting destructor' 

=============================================================

Comment 1

[Stuart Philp :sphilp]

Nils, would you be able to look?

Comment 2

[Andreas Pehrson [:pehrsons]]

Looking at a 64 report [1] I see the stack:
0 ntdll.dll KiFastSystemCallRet 	
1 ntdll.dll ZwWaitForSingleObject 	
2 kernelbase.dll WaitForSingleObjectEx 	
3 kernel32.dll WaitForSingleObjectExImplementation 	
4 kernel32.dll WaitForSingleObject 	
5 mmdevapi.dll CDeviceEnumerator::DestroyHWndNotificationThread() 	
6 mmdevapi.dll CDeviceEnumerator::ReleaseHWndNotification() 	
7 mmdevapi.dll _chkstk 	
8 xul.dll void mozilla::audio::AudioNotification::~AudioNotification()
9 xul.dll void mozilla::StaticAutoPtr<mozilla::audio::AudioNotification>::Assign(class mozilla::audio::AudioNotification*)
10 xul.dll mozilla::KillClearOnShutdown(mozilla::ShutdownPhase)
11 xul.dll static nsresult mozilla::ShutdownXPCOM(class nsIServiceManager*)

AudioNotification seems to be from bug 1361336. Chun-Min, could you take a look?


[1] https://crash-stats.mozilla.com/report/index/6313fe10-fd59-4e02-931f-181e20181119

Comment 3

[C.M.Chang[:chunmin]]

Sure. I'll take a look. Thanks!

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to C.M.Chang[:chunmin] from comment #3)

Sure. I'll take a look. Thanks!

reporter has a fair number of graphics crashes - https://mzl.la/31WSJoQ

Comment 5

[C.M.Chang[:chunmin]]

The whole AudioNotification things should be removed once the AudioIPC is enabled on Windows. The AudioNotification is used to pass the device-change event over IPC.

Comment 6

[C.M.Chang[:chunmin]]

Matthew, should the AudioNotification{Sender, Receiver} be disabled in Nightly on Windows, given that the AudioIPC is enabled in Nightly on Windows? IIRC, AudioNotification{Sender, Receiver} is introduced when the content process has no way to receive the device-change event (bug 1361336) at the time it was implemented. Is it still needed after AudioIPC is enabled? If there is no need, AudioNotificationReceiver and AudioNotificationSender should be disabled. The whole workflow is illustrated here.

Comment 7

[Matthew Gregan [:kinetik]]

Yeah, we can disable AudioNotification{Sender, Receiver} on Nightly (and let it ride the trains with AudioIPC) now, thanks for reminding me! We'll also need to update sCubebDisableDeviceSwitching in CubebUtils at the same time or remove the XP_WIN part of GetDefaultStreamPrefs().

Comment 8

[Worcester12345]

(In reply to C.M.Chang[:chunmin] (PTO) from comment #5)

The whole AudioNotification things should be removed once the AudioIPC is enabled on Windows. The AudioNotification is used to pass the device-change event over IPC.

Was this enabled? Did it fix anything?

(In reply to Matthew Gregan [:kinetik] from comment #7)

Yeah, we can disable AudioNotification{Sender, Receiver} on Nightly (and let it ride the trains with AudioIPC) now, thanks for reminding me! We'll also need to update sCubebDisableDeviceSwitching in CubebUtils at the same time or remove the XP_WIN part of GetDefaultStreamPrefs().

Also, were these done?

Comment 9

[Matthew Gregan [:kinetik]]

(In reply to Worcester12345 from comment #8)

(In reply to C.M.Chang[:chunmin] (PTO) from comment #5)

The whole AudioNotification things should be removed once the AudioIPC is enabled on Windows. The AudioNotification is used to pass the device-change event over IPC.

Was this enabled? Did it fix anything?

(In reply to Matthew Gregan [:kinetik] from comment #7)

Yeah, we can disable AudioNotification{Sender, Receiver} on Nightly (and let it ride the trains with AudioIPC) now, thanks for reminding me! We'll also need to update sCubebDisableDeviceSwitching in CubebUtils at the same time or remove the XP_WIN part of GetDefaultStreamPrefs().

Also, were these done?

Bug 1689516 tracks these changes.

Comment 10

[Worcester12345]

(In reply to C.M.Chang[:chunmin] from comment #5)

The whole AudioNotification things should be removed once the AudioIPC is enabled on Windows. The AudioNotification is used to pass the device-change event over IPC.

(In reply to Matthew Gregan [:kinetik] from comment #7)

Yeah, we can disable AudioNotification{Sender, Receiver} on Nightly (and let it ride the trains with AudioIPC) now, thanks for reminding me! We'll also need to update sCubebDisableDeviceSwitching in CubebUtils at the same time or remove the XP_WIN part of GetDefaultStreamPrefs().

Has this been done?

Comment 11

[BugBot [:suhaib / :marco]]

Closing because no crashes reported for 12 weeks.

Comment 12

[Worcester12345]

Maybe "WONTFIX" instead?

Comment 13

[Wayne Mery (:wsmwk)]

No, not unless you have proof there is still something broken.

WONTFIX means a bug still exists that we are choosing not to fix. But WORKSFORME here means the bug is assumed to NOT exist because, proof, there are no crashes.