Crash in guard_dispatch_icall_nop
Categories
(Core :: General, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox61 | --- | affected |
People
(Reporter: lizzard, Unassigned)
References
Details
(Keywords: crash)
Crash Data
This bug was filed from the Socorro interface and is report bp-c556234a-ca05-4735-b1dc-83dfa0180409. ============================================================= Came across this Windows plugin/content crash during Nightly (61) triage. Most of the reports are marked as potentially exploitable. There are also around 30 crashes in 59.0.2 and a few as far back as 55. Top 9 frames of crashing thread: 0 audioses.dll guard_dispatch_icall_nop 1 audioses.dll CLockedList<ATL::CComPtr<IAudioSessionEvents>, 0, 1>::ForEachEntry 2 audioses.dll CAudioSessionControl::OnAudioSessionEvent 3 audioses.dll CAudioSessionControl::CAudioSessionNotificationDelegator::OnMediaNotification 4 mmdevapi.dll CMediaNotifications::OnMediaNotificationWorkerHandler 5 ntdll.dll TppSimplepExecuteCallback 6 ntdll.dll TppWorkerThread 7 kernel32.dll BaseThreadInitThunk 8 ntdll.dll RtlUserThreadStart =============================================================
|
||
Comment 1•6 years ago
|
||
Tom: this kind of looks like a CFG check, except I thought that didn't report to crash-stats? In any case this is crashing wholly in someone else's modules, some kind of audio thing. Bad driver? The crashing function sounds like it's a safety check so probably not worrying?
|
||
Comment 2•6 years ago
|
||
So guard_dispatch_icall_nop is supposedly just 'jmp rax' and while it may be related to CFG, I am not certain this is actually a CFG failure. In theory CFG failures don't report to crash-stats and they supposedly look like
> Unhandled exception at 0x77C46170 (ntdll.dll) in firefox.exe: RangeChecks instrumentation code detected an out of range array access.|
|
||
Comment 3•6 years ago
|
||
Not crashing in our code. Not sure it needs tracking as a top crash but that's probably the best way to handle this.
|
||
Comment 4•6 years ago
|
||
Callstacks are all over the place here. May or may not be playback related.
|
||
Updated•6 years ago
|
| Comment hidden (Intermittent Failures Robot) |
|
||
Updated•3 years ago
|
|
|
||
Comment 6•3 years ago
|
||
Clearing and resetting the signature field in the hope that this will make Socorro notice the bug.
|
||
Updated•2 years ago
|
|
||
Comment 7•2 years ago
|
||
This doesn't appear to be specifically related to media. Stacks are all over the place, in multiple processes. Core General seems the best place for this. Gcp any thoughts?
|
||
Comment 8•2 years ago
•
|
||
I think the proper fix here is to ignore that stack frame in Socorro, so it gets split on the preceding frame, and then close this bug (...and let others get filed in the actual offending code/components!).
|
||
Comment 9•2 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #8)
I think the proper fix here is to ignore that stack frame in Socorro, so it gets split on the preceding frame, and then close this bug (...and let others get filed in the actual offending code/components!).
Yes, I'll file a bug for that.
|
||
Comment 10•2 years ago
|
||
Gabriele, since we fixed Bug 1798480, does this render this bug as a WORKSFORME?
|
|
||
Comment 11•2 years ago
|
||
Yes given that the original signature was generic and I can't find crashes with the stack trace in comment 0 anymore. I'd say we close it as INCOMPLETE. Most crashes under the old signature (and _guard_dispatch_icall_nop) have morphed into this new one:
We should file a new bug for it
|
||
Comment 12•1 year ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #11)
Yes given that the original signature was generic and I can't find crashes with the stack trace in comment 0 anymore. I'd say we close it as INCOMPLETE. Most crashes under the old signature (and _guard_dispatch_icall_nop) have morphed into this new one:
We should file a new bug for it
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1802294
Going to close this per comment 11.
Description
•