Open Bug 1423735 Opened 3 years ago Updated 2 years ago

Crash in SPipelineState::TrimAllHWM

Categories

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

57 Branch
x86_64
Windows
defect

Tracking

()

Tracking Status
firefox-esr52 --- affected
firefox57 --- affected
firefox58 --- affected
firefox59 --- affected

People

(Reporter: philipp, Unassigned, NeedInfo)

References

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is
report bp-ee5bb2db-29f9-491c-b66f-bdc770171206.
=============================================================

Top 5 frames of crashing thread:

0 d3d11.dll SPipelineState::TrimAllHWM 
1 atidxx64.dll atidxx64.dll@0x53ff9 
2 atidxx64.dll atidxx64.dll@0x2f6643 
3 d3d11.dll CContext::OnRender 
4 d3d11.dll NDXGI::CDevice::RenderCB 

=============================================================

this crash signature during media playback is from windows 7 users on 64bit only and probably got more common mid october due to the win64 migration of release users.

a couple of older ati/amd gpus and drivers seem affected:

Adapter driver version facet
1 	8.653.0.0 	2166 	48.82 %
2 	8.641.0.0 	482 	10.86 %
3 	8.652.0.0 	367 	8.27 %
4 	8.640.0.0 	303 	6.83 %
5 	8.641.1.1000 	201 	4.53 %
6 	8.650.0.0 	191 	4.30 %
7 	8.970.100.1100 	154 	3.47 %
8 	8.660.0.0 	116 	2.61 %
9 	8.641.1.0 	95 	2.14 %
10 	8.652.1.0 	66 	1.49 %

Adapter device id facet
1 	0x954f 	928 	20.92 %
2 	0x9553 	710 	16.00 %
3 	0x9710 	396 	8.92 %
4 	0x9552 	333 	7.51 %
5 	0x9616 	331 	7.46 %
6 	0x9480 	302 	6.81 %
7 	0x95c4 	259 	5.84 %
8 	0x9591 	167 	3.76 %
9 	0x95c5 	167 	3.76 %
10 	0x9498 	118 	2.66 %
Component: Audio/Video → Audio/Video: Playback
under windows 10 the reports appear to have the signature [@ SPipelineStageState::TrimAllHWM]
Crash Signature: [@ SPipelineState::TrimAllHWM] → [@ SPipelineState::TrimAllHWM] [@ SPipelineStageState::TrimAllHWM]
OS: Windows 7 → Windows
Milan and Peter,
The crash rate is quite high and its report looks like more related to graphics to me. 
May we have your help check it?
Flags: needinfo?(milan)
Flags: needinfo?(howareyou322)
This could be a non-Intel version of bug 1292923?
Flags: needinfo?(milan) → needinfo?(matt.woodrow)
It's hard to say, I can't find a way to tell what else we're running on the crashing thread.

It does look like a multi-thread device issue though, so it's certainly possible.

Can we ask AMD to look at a crash dump and see they can figure anything else out?
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(howareyou322)
(In reply to Matt Woodrow (:mattwoodrow) from comment #4)
> It's hard to say, I can't find a way to tell what else we're running on the
> crashing thread.
> 
> It does look like a multi-thread device issue though, so it's certainly
> possible.
> 
> Can we ask AMD to look at a crash dump and see they can figure anything else
> out?
Kyle,
Per comment 4, can you help us check it?
Flags: needinfo?(kyle.plumadore)
Paul,
Since Kyle is not available until next year, would you be available to help us check this bug per comment 4?
Flags: needinfo?(paul.blinzer)
We will investigate
Flags: needinfo?(paul.blinzer)
Pretty much all of the affected device IDs are long EOL'ed (> 5 years) and no new driver updates are planned for these devices. 
Most of the affected The driver revisions affected are not the last ones released for these devices however, though most of the affected don't seem to use the last one released (8.970.100) and available here:  

http://support.amd.com/en-us/download/desktop/legacy?product=legacy2&os=Windows%208%20-%2064

Based on the offsets, the most likely root cause seems indeed to be a multi-threading issue when using the Render() API along with some context state change (from the source it is not clear exactly what other operation occurred).
The suggested approach is to ensure that reentry is avoided when calling down to the runtime/driver.
You need to log in before you can comment on or make changes to this bug.