Crash in [@ rx::Clear11::clearFramebuffer]
Categories
(Core :: Graphics: WebRender, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox71 | --- | unaffected |
| firefox72 | --- | unaffected |
| firefox73 | --- | fixed |
People
(Reporter: jseward, Assigned: sotaro)
References
Details
(Keywords: crash, regression)
Crash Data
This bug is for crash report bp-e4e2d604-2750-44e1-bcd5-adde20191214.
This signature occurred 4 times in 4 different installations in the Windows
nightly 20191212095326.
Top 10 frames of crashing thread:
0 libglesv2.dll rx::Clear11::clearFramebuffer gfx/angle/checkout/src/libANGLE/renderer/d3d/d3d11/Clear11.cpp:379
1 libglesv2.dll angle::Result rx::Framebuffer11::clearImpl gfx/angle/checkout/src/libANGLE/renderer/d3d/d3d11/Framebuffer11.cpp
2 libglesv2.dll rx::FramebufferD3D::clear gfx/angle/checkout/src/libANGLE/renderer/d3d/FramebufferD3D.cpp:104
3 libglesv2.dll gl::Framebuffer::clear gfx/angle/checkout/src/libANGLE/Framebuffer.cpp:1367
4 libglesv2.dll gl::Context::clear gfx/angle/checkout/src/libANGLE/Context.cpp:3645
5 xul.dll static void webrender::device::gl::Device::clear_target gfx/wr/webrender/src/device/gl.rs:3225
6 xul.dll static void webrender::renderer::Renderer::draw_frame gfx/wr/webrender/src/renderer.rs:5292
7 @0x2030c51f5ff
8 xul.dll static union core::result::Result<webrender::renderer::RenderResults, alloc::vec::Vec<webrender::renderer::RendererError>> webrender::renderer::Renderer::render_impl gfx/wr/webrender/src/renderer.rs:3102
9 xul.dll static union core::result::Result<webrender::renderer::RenderResults, alloc::vec::Vec<webrender::renderer::RendererError>> webrender::renderer::Renderer::render gfx/wr/webrender/src/renderer.rs:2924
|
||
Comment 1•5 years ago
|
||
Crash when clearing a picture cache target. This is nightly only, so perhaps is due to compositor work? First build ID is 20191209095039 which coincides with flipping the pref. Numbers aren't massive but probably worth keeping an eye on!
|
||
Comment 2•5 years ago
|
||
Adding Glenn to take a look too and make sure this one impact release
|
||
Comment 3•5 years ago
|
||
We disabled the compositor by default yesterday - so let's keep an eye on the crash rate and see if it drops to 0 in the nightly that this occurred?
|
Assignee | |
Comment 4•5 years ago
•
|
||
Majority of error logs has DXGI_ERROR_DEVICE_REMOVED(0x887a0005) error at DCompositionSurface::BeginDraw. We needs to handles device resent more. Then disabling WR compositor reduce the crash.
On some drivers, when device reset happens we needs to stop using the D3DDevice, otherwise crash could happen. Current WebRender does not stop gl rendering in this case.
|
|
Assignee | |
Comment 5•5 years ago
|
||
I take a look.
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 6•5 years ago
|
||
When device reset happens, DirectCompositionDevice is not re-created. Then it caused DCompositionSurface::BeginDraw failed with DXGI_ERROR_DEVICE_REMOVED(0x887a0005) error. DirectCompositionDevice needs to be updated.
|
|
Assignee | |
Comment 7•5 years ago
|
||
When ANGLE detected a device reset, ANGLE released D3D11 resources at Renderer11::release().
And Renderer11::mClear was not re-created. Then clear caused the crash. When Renderer11::release() was called, callstack was like the following.
Renderer11::release()
Renderer11::resetDevice()
DisplayD3D::restoreLostDevice()
Display::restoreLostDevice()
Display::createImage()
EGL_CreateImageKHR()
DCLayer::CreateEGLSurfaceForCompositionSurface()
DCLayerTree::Bind()
RenderCompositorANGLE::Bind()
|
|
Assignee | |
Comment 8•5 years ago
•
|
||
Renderer11::resetDevice() calls Renderer11::initialize() after Renderer11::release() call.
But Renderer11::initialize() did not re-allocate Renderer11::mClear. Since Renderer11::initializeD3DDevice() was failed because Renderer11 held obsoleted D3DDevice.
D3DDevice was provided by gecko int GetAndInitDisplayForWebRender() and ANGLE could not re-create D3DDevice.
|
|
Assignee | |
Comment 9•5 years ago
|
||
When GL_LOSE_CONTEXT_ON_RESET_EXT is set, Display::restoreLostDevice() does not call DisplayD3D::restoreLostDevice().
|
|
Assignee | |
Comment 10•5 years ago
•
|
||
(In reply to Sotaro Ikeda [:sotaro away Dec/28 - Jan/5] from comment #9)
When GL_LOSE_CONTEXT_ON_RESET_EXT is set, Display::restoreLostDevice() does not call DisplayD3D::restoreLostDevice().
It could be set with EGL_LOSE_CONTEXT_ON_RESET.
EGL_LOSE_CONTEXT_ON_RESET could be enabled by CreateContextFlags::PREFER_ROBUSTNESS flag.
|
||
Comment 11•5 years ago
|
||
This went away and it looks like Sotaro understands what's going on.
|
||
Comment 12•5 years ago
|
||
I assume it was preffing off gfx.webrender.compositor in bug 1604088 which made this go away.
|
||
Comment 13•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Description
•