Closed Bug 1507182 Opened 5 years ago Closed 2 years ago

Crash in shutdownhang | CDeviceEnumerator::DestroyHWndNotificationThread

Categories

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

63 Branch
x86
Windows 7
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: worcester12345, Unassigned)

References

Details

(Whiteboard: [tbird crash] [media-crash] [AudioNotification])

Crash Data

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' 

=============================================================
Nils, would you be able to look?
Component: General → Audio/Video
Flags: needinfo?(drno)
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
Status: UNCONFIRMED → NEW
Rank: 17
Ever confirmed: true
Flags: needinfo?(drno) → needinfo?(cchang)
Priority: -- → P2
See Also: → 1419488
Sure. I'll take a look. Thanks!
Flags: needinfo?(cchang)
See Also: → 1540883

(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

Flags: needinfo?(cchang)
Whiteboard: [tbird crash]

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.

Flags: needinfo?(cchang)

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.

Flags: needinfo?(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().

Flags: needinfo?(kinetik)
Priority: P2 → P3
Whiteboard: [tbird crash] → [tbird crash] [media-crash] [AudioNotification]

(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?

Flags: needinfo?(kinetik)
Flags: needinfo?(cchang)
See Also: → 1689516

(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.

Flags: needinfo?(kinetik)
Flags: needinfo?(cchang)
QA Whiteboard: qa-not-actionable

(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?

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.