1295742 - Crash in UMDevice::ClearRenderTargetView

Status: RESOLVED INACTIVE

(Core :: Graphics, defect, P3)

Description

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

This bug was filed from the Socorro interface and is 
report bp-80efd62d-5eaf-4cae-ad4c-226da2160816.
=============================================================

Driver upgrade leads to this one, but there are others that may be for other reasons.  Searching for CompositingRenderTargetD3D11::BindRenderTarget in the proto signature is a good way to go.

Comment 1

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

https://crash-stats.mozilla.com/search/?product=Firefox&proto_signature=~CompositingRenderTargetD3D11%3A%3ABindRenderTarget&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

One message in the comment 0 crash is the VendorIDMismatch one.

Peter, anything we can save here?

Comment 2

[Peter Chang[:pchang]]

There was another crash report that showed driver reset.

https://crash-stats.mozilla.com/report/index/80efd62d-5eaf-4cae-ad4c-226da2160816

|[0][GFX1-]: Detected rendering device reset on refresh: 3 (t=15839.7)

I think we need to check the device status somewhere before render.
Ethan, could you check with Jerry how to prevent this?

Comment 3

[Ethan Lin[:ethlin]]

(In reply to Peter Chang[:pchang] from comment #2)
> There was another crash report that showed driver reset.
> 
> https://crash-stats.mozilla.com/report/index/80efd62d-5eaf-4cae-ad4c-
> 226da2160816
> 
> |[0][GFX1-]: Detected rendering device reset on refresh: 3 (t=15839.7)
> 
> I think we need to check the device status somewhere before render.
> Ethan, could you check with Jerry how to prevent this?

Okay, I will check with Jerry.

Comment 4

[Peter Chang[:pchang]]

Paste the correct one with "driver reset log".

https://crash-stats.mozilla.com/report/index/b748d65f-f50e-4793-9f2c-bfdbc2160817

Comment 5

[Ethan Lin[:ethlin]]

It looks like the FF crashed in composition before driver reset finished. Currently we only print log after finishing the driver reset. Per discussion with Jerry, we should add log when we detect driver changed. In this case, we may do some error handling in composition to prevent this kind crash.

Comment 6

[Ethan Lin[:ethlin]]

Attachment: Add log for device reset

Originally we only add log in the end of gfxWindowsPlatform::SchedulePaintIfDeviceReset. But it's possible to trigger device reset from nsWindow::OnPaint. Moreover, we want to know if the process of driver reset has started when crash. So I add logs to embrace the device reset action in gfxWindowsPlatform and nsWindow.

Comment 7

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

Crash volume for signature 'UMDevice::ClearRenderTargetView':
 - nightly (version 51): 0 crashes from 2016-08-01.
 - aurora  (version 50): 0 crashes from 2016-08-01.
 - beta    (version 49): 4 crashes from 2016-08-02.
 - release (version 48): 32 crashes from 2016-07-25.
 - esr     (version 45): 0 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       0       0       0
 - aurora        0       0       0
 - beta          1       0       1
 - release      11       9       6
 - esr           0       0       0

Affected platform: Windows

Crash rank on the last 7 days:
           Browser     Content   Plugin
 - nightly
 - aurora
 - beta    #4961
 - release #2173
 - esr

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/396585308c33
Add gfxCriticalNote for driver reset. r=jerry, r=dvander

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/396585308c33

Comment 10

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

The leave-open keyword is there and there is no activity for 6 months.
:davidb, maybe it's time to close this bug?