Closed Bug 1978684 Opened 1 year ago Closed 1 year ago

Crash in [@ Microsoft::WRL::ComPtr<T>::operator int Microsoft::WRL::Details::BoolStruct::* ]

Categories

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

defect

Tracking

()

RESOLVED FIXED
143 Branch
Tracking Status
firefox142 --- fixed
firefox143 --- fixed

People

(Reporter: alwu, Assigned: alwu)

References

Details

Crash Data

Attachments

(2 files)

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.

This patch introduces the creation of mCDMProxy immediately following the
creation of mCDM, utilizing EventTargetAndLockCapability to guarantee
thread-safe interactions between them.

Severity: -- → S3
Pushed by alwu@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/7cc57e0d39eb https://hg.mozilla.org/integration/autoland/rev/9eaae40f35dd part1 : add threading assertions. r=media-playback-reviewers,padenot https://github.com/mozilla-firefox/firefox/commit/5e52b069b410 https://hg.mozilla.org/integration/autoland/rev/d6cb27bee758 part2 : use EventTargetAndLockCapability to ensure the thread safety for mCDM and mCDMProxy. r=media-playback-reviewers,padenot

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!

Flags: needinfo?(gsvelto)

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.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 143 Branch

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
Attachment #9502317 - Flags: approval-mozilla-beta?

(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.

Flags: needinfo?(gsvelto)

:alwu just want to double check you only want to uplift part 1 of your patch

Flags: needinfo?(alwu)

All patches, thanks.

Flags: needinfo?(alwu)

Comment on attachment 9502317 [details]
Bug 1978684 - part1 : add threading assertions.

Approved for 142.0b4

Attachment #9502317 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9502318 - Flags: approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: