Crash in CleanupPerAppKey | `anonymous namespace''::wasapi_stream_render_loop

RESOLVED FIXED in Firefox -esr52

Status

()

Core
Audio/Video: cubeb
P1
critical
Rank:
15
RESOLVED FIXED
11 months ago
10 months ago

People

(Reporter: philipp, Assigned: achronop)

Tracking

({crash, regression})

50 Branch
mozilla55
x86
Windows 8
crash, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox51 wontfix, firefox52 wontfix, firefox-esr52 fixed, firefox53 fixed, firefox54 fixed, firefox55 fixed)

Details

(crash signature)

(Reporter)

Description

11 months ago
This bug was filed from the Socorro interface and is 
report bp-e6040ec8-cde4-4f17-8006-50a352170224.
=============================================================
Crashing Thread (97)
Frame 	Module 	Signature 	Source
0 	ntdll.dll 	NtWaitForMultipleObjects 	
1 	kernelbase.dll 	CleanupPerAppKey 	
2 	kernel32.dll 	WaitForMultipleObjects 	
3 	xul.dll 	`anonymous namespace'::wasapi_stream_render_loop 	media/libcubeb/src/cubeb_wasapi.cpp:817
4 	ucrtbase.dll 	_o__CIpow 	
5 	kernel32.dll 	BaseThreadInitThunk 	
6 	ntdll.dll 	__RtlUserThreadStart 	
7 	ntdll.dll 	_RtlUserThreadStart

these crashes in the content process are regressing since firefox 50 builds. this signature seems to be exclusive to windows 8.1 users with 32bit versions of firefox.

Correlations for Firefox Release
(100.0% in signature vs 00.52% overall) reason = EXCEPTION_INVALID_HANDLE
(99.58% in signature vs 26.22% overall) Module "RTWorkQ.dll" = true
(65.83% in signature vs 29.07% overall) shutdown_progress = null [100.0% vs 30.14% if process_type = content]
(100.0% in signature vs 30.64% overall) ipc_message_name = null
(100.0% in signature vs 60.73% overall) is_garbage_collecting = null
(99.79% in signature vs 55.19% overall) os_arch = amd64 [99.79% vs 61.04% if process_type = content]
(29.77% in signature vs 86.90% overall) accessibility = null [70.02% vs 29.83% if process_type = content]
(29.98% in signature vs 68.10% overall) abort_message = null

Comment 1

11 months ago
We don't have the plan to have dot release for 51. Mark 51 won't fix.
status-firefox51: affected → wontfix

Updated

11 months ago
Flags: needinfo?(kinetik)
Paul, is this a variant of bug 1326176?
Flags: needinfo?(kinetik) → needinfo?(padenot)
Rank: 15
Priority: -- → P1

Comment 3

11 months ago
Matthew, kind of. As it appears, in certain configurations of Windows, you can't pass an invalid handle to `WaitForMultipleObject`. In practice, this is an UB:

"If one of these handles is closed while the wait is still pending, the function's behavior is undefined."

I'll get us a fix as soon as possible.
Assignee: nobody → padenot
Flags: needinfo?(padenot)
(Assignee)

Updated

10 months ago
Depends on: 1345049

Updated

10 months ago
Depends on: 1347944
(Assignee)

Comment 4

10 months ago
Landed in m-c with Bug 1345049. Uplifted in 54, 53, esr52 with Bug 1347944.
Assignee: padenot → achronop
Status: NEW → RESOLVED
Last Resolved: 10 months ago
status-firefox52: affected → wontfix
status-firefox53: affected → fixed
status-firefox54: ? → fixed
status-firefox55: --- → fixed
status-firefox-esr52: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.