Closed Bug 1295742 Opened 3 years ago Closed Last year
Crash in UMDevice::Clear
Render Target View
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.
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?
There was another crash report that showed driver reset. https://crash-stats.mozilla.com/report/index/80efd62d-5eaf-4cae-ad4c-226da2160816 |[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
(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 > > |[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.
Paste the correct one with "driver reset log". https://crash-stats.mozilla.com/report/index/b748d65f-f50e-4793-9f2c-bfdbc2160817
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) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/396585308c33 Add gfxCriticalNote for driver reset. r=jerry, r=dvander
2 years ago
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?
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.