1423735 - Crash in SPipelineState::TrimAllHWM

Status: RESOLVED WORKSFORME

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

Description

[[:philipp]]

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 %

Comment 1

[[:philipp]]

under windows 10 the reports appear to have the signature [@ SPipelineStageState::TrimAllHWM]

Comment 2

[Blake Wu [:bwu][:blakewu]]

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?

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

This could be a non-Intel version of bug 1292923?

Comment 4

[Matt Woodrow (:mattwoodrow)]

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?

Comment 5

[Blake Wu [:bwu][:blakewu]]

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

Comment 6

[Blake Wu [:bwu][:blakewu]]

Paul,
Since Kyle is not available until next year, would you be available to help us check this bug per comment 4?

Comment 7

[Paul Blinzer]

We will investigate

Comment 8

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

Comment 9

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

Closing because no crashes reported for 12 weeks.

Comment 10

[Paul Blinzer]

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #9)

Closing because no crashes reported for 12 weeks.

Were there any dedicated changes to the code to address this?