1285152 - Crash in CContext::TID3D11DeviceContext_SetShaderResources_<T>

Status: NEW

(Core :: Graphics, defect, P3)

Description

[Jerry Shih[:jerry] (UTC+8) (inactive)]

There are a lot of crash at CContext::TID3D11DeviceContext_SetShaderResources_<T>.

Most of crash reports have driver-reset log. So, I think it's a driver-reset problem.

https://crash-stats.mozilla.com/search/?signature=~TID3D11DeviceContext_SetShaderResources&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

Comment 1

[Jerry Shih[:jerry] (UTC+8) (inactive)]

I use a command "dxcap -forcetdr" to test driver remove/reset with my simple d3d11 app.
When the driver reset, the app is usually crashed at ID3D11DeviceContext::PSSetShaderResources() and other ID3D11DeviceContext::XXX interface.
The "ID3D11DeviceContext::PSSetShaderResources()" has no return value, and the function parameter look fine.
So, I don't know how to prevent the crash in PSSetShaderResources() call.

There is one article for driver reset handling[1]. It says that we should check the device status after
"swapChain::Present()" and "swapChain::ResizeBuffers" calls. I think we could have a flag to skip all d3d11 call after we get driver reset from Present() or ResizeBuffers(). Then wait the gecko main thread to handle the driver reset. I do the similar thing with my simple d3d11 app, and I don't see crash anymore.

[1]
https://msdn.microsoft.com/en-us/windows/uwp/gaming/handling-device-lost-scenarios

Comment 2

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

Jerry, see bug 1278973 where I raised this issue (same article :), but Bas and David thought at the time we didn't need to do this.  Perhaps this is new information.
I'd like to see a prototype of checking right after Present() and see if it deals with the issue you describe above.

Comment 3

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Not only d3d11 but also d2d should handle the device-removed.
Some crash-dumps show that the "TID3D11DeviceContext_SetShaderResources_()" is called from DrawTargetD2D::flush().

From https://msdn.microsoft.com/zh-tw/library/windows/desktop/ff684174(v=vs.85).aspx :
Handling Device Loss
While your program is running, the graphics device that you are using might become unavailable. For example, the device can be lost if the display resolution changes, or if the user removes the display adapter. If the device is lost, the render target also becomes invalid, along with any device-dependent resources that were associated with the device. Direct2D signals a lost device by returning the error code D2DERR_RECREATE_TARGET from the EndDraw method. If you receive this error code, you must re-create the render target and all device-dependent resources.

---
For compositor side, we check the device status for every beginning of frame(Compositor::BeginFrame()), so maybe it doesn't need to check the Present() or ResizeBuffers() call return value.
But there are still some crash at compositorParent. :(
https://crash-stats.mozilla.com/report/index/d254cb5e-65da-4505-a201-63f512160722

Comment 4

[u279076]

Based on the data it looks like this crash started on June 22nd along with bug 1285333 and bug 1292311 which suggests this regression window: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d224fc999cb6&tochange=2e3390571fdb

Comment 5

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

Right - chances are, that regression range contains something that increases the frequency of driver resets, and this is one of the driver reset handling bugs.

Comment 8

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

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 5 GPU process crashes on release

:bhood, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Comment 9

[Bob Hood [:bhood]]

Crash data above shows almost nothing on the radar.

Comment 10

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

Based on the topcrash criteria, the crash signatures linked to this bug are not in the topcrash signatures anymore.

For more information, please visit auto_nag documentation.