1652696 - Crash in [@ CoInitializeEx]

Status: RESOLVED WORKSFORME

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

Description

[Alex Chronopoulos [:achronop]]

This bug is for crash report bp-5e31eb60-9c42-4c29-aeba-618140200612.

Top 7 frames of crashing thread:

0 ole32.dll CoInitializeEx 
1 xul.dll void `anonymous namespace'::wasapi_stream_render_loop::auto_com::auto_com media/libcubeb/src/cubeb_wasapi.cpp:1110
2 xul.dll static unsigned int `anonymous namespace'::wasapi_stream_render_loop media/libcubeb/src/cubeb_wasapi.cpp:1108
3 ucrtbase.dll thread_start<unsigned int > 
4  @0x2a15012a 
5 mozglue.dll static void patched_BaseThreadInitThunk mozglue/build/WindowsDllBlocklist.cpp:629
6 ntdll.dll RtlUserThreadStart 

Comment 1

[Alastor Wu [:alwu]]

This crash happened in cubeb_wasapi, so move it to cubeb component.

Comment 2

[Alex Chronopoulos [:achronop]]

Here is the crashes for the last 6 months.

Not all of them are playback crashes. From those that are playback crashes, some of them does not include wasapi in the stack, like:

https://crash-stats.mozilla.org/report/index/b1797d99-4cde-42a5-a608-d9d980200210
https://crash-stats.mozilla.org/report/index/16e10213-3852-44a1-8e89-f2df50200713

Can you please have a look at those and tell us what you think?

Comment 3

[C.M.Chang[:chunmin]]

(In reply to Alex Chronopoulos [:achronop] from comment #2)

Not all of them are playback crashes.

Take a look at the API doc, maybe CoInitializeEx is called from the DllMain function so we get some crashes. Widget team may have better insights into what's going on I guess.

Hi Molly,

I was wondering if you have any idea about this issue.

Comment 4

[Molly Howell (she/her) (mostly inactive)]

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

Hi Molly,

I was wondering if you have any idea about this issue.

Wow, no, not really, this signature is pretty surprising to see. I don't think the DllMain theory is supported, because the crashes don't seem to be inside any DllMain, and because CoInitializeEx itself appears to have special handing for that case.

There are actually several different kinds of crashes under this signature. Some of them are simple stack overflows. On the other hand, bp-5e31eb60-9c42-4c29-aeba-618140200612 really looks like the internal state around the special reserved-for-OLE thread-local storage area is corrupt for the crashing thread; It's a brand new thread, so nothing should be initialized yet, but COM seems to have decided that it was initialized and tried to read some data that didn't exist. I don't really have an explanation for any of that, but it seems rare enough that I'm having a hard time getting very concerned.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.