Crash in [@ RtlRaiseStatus | RtlLeaveCriticalSection | (anonymous namespace)::refill]
Categories
(Core :: Audio/Video: cubeb, defect)
Tracking
()
People
(Reporter: gsvelto, Unassigned)
Details
(Keywords: crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/69153fe0-45a9-418c-8391-68f010220409
Reason: EXCEPTION_INVALID_HANDLE
Top 9 frames of crashing thread:
0 ntdll.dll RtlRaiseStatus
1 ntdll.dll RtlLeaveCriticalSection
2 xul.dll `anonymous namespace'::refill media/libcubeb/src/cubeb_wasapi.cpp:881
3 xul.dll `anonymous namespace'::refill_callback_output media/libcubeb/src/cubeb_wasapi.cpp:1256
4 xul.dll `anonymous namespace'::wasapi_stream_render_loop media/libcubeb/src/cubeb_wasapi.cpp:1394
5 ucrtbase.dll thread_start<unsigned int , 1>
6 kernel32.dll BaseThreadInitThunk
7 mozglue.dll patched_BaseThreadInitThunk toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp:576
8 ntdll.dll RtlUserThreadStart
Windows-specific crash. I don't see any code dealing with handles in the affected function but maybe it's been inlined from somewhere else.
|
||
Comment 1•2 years ago
|
||
Since the beginning of last December it seems like.
The bad handle is the lock, on the scope exit of the auto_lock. Coincidentally, kinetik has just changed a few things about lifetime not too far from here (not landed in mozilla-central yet), but this one is weird: locking worked, unlocking crashed, and there is a(nother) regular cubeb_stream_init in another thread (not e.g. a reinit), so we're quite sure the audio callbacks isn't live yet. There is not cubeb_stream_stop (that returns after the callback has stopped) in any stack so maybe we have a stray render thread somehow?
We'll make all this lock-free eventually, but something sounds off.
|
||
Updated•2 years ago
|
|
||
Comment 2•1 year ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•