This bug was filed from the Socorro interface and is report bp-181b4035-4f50-4d8c-afd5-3e44d2141119. ============================================================= Top frames: 0 xul.dll mozilla::layers::CompositorD3D11::HandleError(long, mozilla::layers::CompositorD3D11::Severity) gfx/layers/d3d11/CompositorD3D11.cpp 1 xul.dll mozilla::layers::CompositorD3D11::Failed(long, mozilla::layers::CompositorD3D11::Severity) gfx/layers/d3d11/CompositorD3D11.cpp 2 xul.dll mozilla::layers::CompositorD3D11::UpdateRenderTarget() gfx/layers/d3d11/CompositorD3D11.cpp 3 xul.dll mozilla::layers::CompositorD3D11::BeginFrame(nsIntRegion const&, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits> const*, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits>*, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits>*) gfx/layers/d3d11/CompositorD3D11.cpp 4 xul.dll mozilla::layers::LayerManagerComposite::Render() gfx/layers/composite/LayerManagerComposite.cpp 5 xul.dll mozilla::layers::LayerManagerComposite::EndTransaction(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, nsIntRegion const&, mozilla::layers::DrawRegionClip, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) gfx/layers/composite/LayerManagerComposite.cpp 6 xul.dll mozilla::layers::LayerManagerComposite::EndEmptyTransaction(mozilla::layers::LayerManager::EndTransactionFlags) gfx/layers/composite/LayerManagerComposite.cpp 7 xul.dll mozilla::layers::CompositorParent::CompositeToTarget(mozilla::gfx::DrawTarget*, nsIntRect const*) gfx/layers/ipc/CompositorParent.cpp 8 xul.dll mozilla::layers::CompositorParent::CompositeCallback(mozilla::TimeStamp) gfx/layers/ipc/CompositorParent.cpp 9 xul.dll RunnableMethod<mozilla::layers::CompositorParent, void ( mozilla::layers::CompositorParent::*)(mozilla::TimeStamp), Tuple1<mozilla::TimeStamp> >::Run() ipc/chromium/src/base/task.h 10 xul.dll MessageLoop::DoWork() ipc/chromium/src/base/message_loop.cc Since we added the top two frames to the prefix list in bug 1092205, this appears as the largest CompositorD3D11::HandleError signature on Nightly.

At first glance it looks like the same buffers[0] problem. The signature subsided with the fix for bug 1089364 but then sprang back up a few days later: 20141110030204 17 20141111030203 21 20141112030202 37 20141113030201 40 20141114030206 51 20141115030205 9 20141116030212 5 20141117030201 6 20141118030201 7 20141118144012 40 20141119030200 86 20141119030206 2 20141120030202 151 20141121030201 53 20141122030204 58 20141123030204 76 20141124030207 16

User comments include "Updated AMD Radeon drivers" and "installed a new nvidia driver while ff was open"

(In reply to David Major [:dmajor] (UTC+13) from comment #2) > User comments include "Updated AMD Radeon drivers" and "installed a new > nvidia driver while ff was open" Sounds like bug 1086614. It has a patch but I haven't tested it yet (haven't tried to update my driver while firefox is running).

I wonder if crashes like this should have a dependency on bug 1087270, which introduced the MOZ_CRASH this is tripping over. Also, unfortunately, there are two MOZ_CRASH() in CompositorD3D11::HandleError and there's nothing in reports that makes it easy to tell which one it was (the string of the MOZ_CRASH isn't reported anywhere).

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #4) > I wonder if crashes like this should have a dependency on bug 1087270, which > introduced the MOZ_CRASH this is tripping over. bug 1087270 added a way to crash on invalid D3D11 calls but didn't add the code that does invalid things, so I think it'd be more useful to make crashes like this one block the "Bullet-proof D3D11" bug (Bug 1086611).

In the case of the failures following ResizeBuffers, one thing that is worth trying out is to make sure that we clear out the texture in mDefaultRT before nulling the mDefaultRT itself, because just clearing the pointer to the RenderTarget doesn't guarantee that the texture is destroyed since someone could still be referencing the RenderTarget and keeping it alive (all resources belonging to the swapchain must be destroyed before we call ResizeBuffer).

Something like this.

I also got this crash today bp-53949f7f-d102-4dca-b210-e9c142141201

Updated patch

Comment on attachment 8531007 [details] [diff] [review] Make sure the swapchain's textures are cleared before resizing. Review of attachment 8531007 [details] [diff] [review]: ----------------------------------------------------------------- R= Bas over the shoulder

[Tracking Requested - why for this release]: This is showing up on Aurora 36 as a top crasher.

Nical is this safe to put onto Aurora?

Comment on attachment 8531007 [details] [diff] [review] Make sure the swapchain's textures are cleared before resizing. Approval Request Comment [Feature/regressing bug #]: D3D11 OMTC [User impact if declined]: some crashes on windows [Describe test coverage new/current, TBPL]: [Risks and why]: very low, trivial patch [String/UUID change made/needed]: