Crash in [@ Microsoft::WRL::ComPtr<T>::operator int Microsoft::WRL::Details::BoolStruct::* ]
Categories
(Core :: Audio/Video: Playback, defect, P1)
Tracking
()
People
(Reporter: alwu, Assigned: alwu)
References
Details
Crash Data
Attachments
(2 files)
|
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
|
Details | Review |
Crash report : https://crash-stats.mozilla.org/report/index/69309bec-0157-42a0-a3b3-dfdd80250630
According to our crash ping, the volume of this crash is higher than it shows in the crash status.
| Assignee | ||
Comment 1•1 year ago
|
||
| Assignee | ||
Comment 2•1 year ago
|
||
This patch introduces the creation of mCDMProxy immediately following the
creation of mCDM, utilizing EventTargetAndLockCapability to guarantee
thread-safe interactions between them.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 4•1 year ago
|
||
Hi, Gabriele,
For this crash signature, I found that the result reported from the crash stats and crash pings are very different. On crash ping, it has around 60000 pings in the past three weeks, but almost zero on the crash-stats. Do you have any idea about that? Thanks!
| Assignee | ||
Comment 5•1 year ago
|
||
Same situation also happens on the signature <unknown in igd10um64xe.dll> | NDXGI::CDevice::CreateDriverInstance, on the crash stats its crash volume is way way more smaller than the result from the crash ping.
Comment 6•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/9eaae40f35dd
https://hg.mozilla.org/mozilla-central/rev/d6cb27bee758
| Assignee | ||
Comment 7•1 year ago
•
|
||
Comment on attachment 9502317 [details]
Bug 1978684 - part1 : add threading assertions.
Beta/Release Uplift Approval Request
- User impact if declined/Reason for urgency: Crash during DRM playback. Therefore, according to our crash ping, the volume of this crash is way higher than it shows in the crash status.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: all patches in this bug
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is about adding thread safety protection to prevent from getting data race, not new functionality, or big change.
- String changes made/needed:
- Is Android affected?: No
Comment 8•1 year ago
|
||
(In reply to Alastor Wu [:alwu] from comment #4)
Hi, Gabriele,
For this crash signature, I found that the result reported from the crash stats and crash pings are very different. On crash ping, it has around 60000 pings in the past three weeks, but almost zero on the crash-stats. Do you have any idea about that? Thanks!
This is a utility process crash so the user has no way to report it unless they do it from about:crashes or they are on nightly and have auto-submission enabled. Because the utility process is automatically restarted it can go in a crash loop where we get a lot of pings but no reports.
Comment 9•1 year ago
|
||
:alwu just want to double check you only want to uplift part 1 of your patch
Comment 11•1 year ago
|
||
Comment on attachment 9502317 [details]
Bug 1978684 - part1 : add threading assertions.
Approved for 142.0b4
Updated•1 year ago
|
Updated•1 year ago
|
Comment 12•1 year ago
|
||
| uplift | ||
Description
•