Closed Bug 1295742 Opened 3 years ago Closed Last year

Crash in UMDevice::ClearRenderTargetView

Categories

(Core :: Graphics, defect, P3, critical)

x86
Windows 10
defect

Tracking

()

RESOLVED INACTIVE
Tracking Status
firefox48 --- affected
firefox49 --- affected
firefox51 --- affected

People

(Reporter: milan, Assigned: ethlin)

Details

(Keywords: crash, Whiteboard: [gfx-noted])

Crash Data

Attachments

(1 file)

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.
Whiteboard: [gfx-noted]
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?
Assignee: nobody → ethlin
Flags: needinfo?(howareyou322)
(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.
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.
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.
Attachment #8784742 - Flags: review?(hshih)
Attachment #8784742 - Flags: review?(hshih) → review+
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
Attachment #8784742 - Flags: review?(dvander)
Attachment #8784742 - Flags: review?(dvander) → review+
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/396585308c33
Add gfxCriticalNote for driver reset. r=jerry, r=dvander
Keywords: checkin-needed
Priority: -- → P3
The leave-open keyword is there and there is no activity for 6 months.
:davidb, maybe it's time to close this bug?
Flags: needinfo?(dbolter)
Status: NEW → RESOLVED
Closed: Last year
Flags: needinfo?(dbolter)
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.