Closed Bug 1342389 Opened 7 years ago Closed 7 years ago

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

Categories

(Core :: Audio/Video: cubeb, defect, P1)

50 Branch
x86
Windows 8
defect

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox51 --- wontfix
firefox52 --- wontfix
firefox-esr52 --- fixed
firefox53 --- fixed
firefox54 --- fixed
firefox55 --- fixed

People

(Reporter: philipp, Assigned: achronop)

References

Details

(Keywords: crash, regression)

Crash Data

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
We don't have the plan to have dot release for 51. Mark 51 won't fix.
Flags: needinfo?(kinetik)
Paul, is this a variant of bug 1326176?
Flags: needinfo?(kinetik) → needinfo?(padenot)
Rank: 15
Priority: -- → P1
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)
Depends on: 1345049
Depends on: 1347944
Landed in m-c with Bug 1345049. Uplifted in 54, 53, esr52 with Bug 1347944.
Assignee: padenot → achronop
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.