1980057 - Crash in Direct3D 12 when D3D11on12 is set

Status: NEW

(Core :: Graphics: WebGPU, defect, P2)

Description

[Ashley Hale [:ahale]]

Crash report: https://crash-stats.mozilla.org/report/index/b1edb33f-9a1d-4862-8dd7-209100250730

MOZ_CRASH Reason:

Device creation failed: Device lost (The GPU device instance has been suspended. Use GetDeviceRemovedReason to determine the appropriate action. (0x887A0005))

Top 10 frames:

0  xul.dll  MOZ_Crash(char const*, int, char const*)  mfbt/Assertions.h:381
0  xul.dll  RustMozCrash(char const*, int, char const*)  mozglue/static/rust/wrappers.cpp:18
1  xul.dll  mozglue_static::panic_hook(std::panic::PanicHookInfo*)  mozglue/static/rust/lib.rs:99
2  xul.dll  core::ops::function::Fn::call<void (*)(ref$<std::panic::PanicHookInfo>), tupl...  /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/core/src/ops/function.rs:250
3  xul.dll  alloc::boxed::impl$30::call()  library/alloc/src/boxed.rs:1990
3  xul.dll  std::panicking::rust_panic_with_hook()  library/std/src/panicking.rs:839
4  xul.dll  std::panicking::begin_panic_handler::closure$0()  library/std/src/panicking.rs:704
5  xul.dll  std::sys::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_h...  library/std/src/sys/backtrace.rs:168
6  xul.dll  std::panicking::begin_panic_handler()  library/std/src/panicking.rs:695
7  xul.dll  core::panicking::panic_fmt()  library/core/src/panicking.rs:75

Comment 1

[Ashley Hale [:ahale]]

Attachment: about:support

Attached about:support, a crash to go with this particular instance of the browser is here: https://crash-stats.mozilla.org/report/index/ce9e834a-2a29-4475-9417-9f2ad0250730

STR:

• Start Firefox 141
• Go to a YouTube short (in this case I was visiting https://www.youtube.com/shorts/Kn6yEyaeGaM as a test).
• Go to https://www.wide-gamut.com/test
• Go to about:support
  • (this crashes the GPU process for whatever reason it seems)
• Go to about:crashes and submit the crash report

Comment 2

[Jim Blandy :jimb]

Thanks! All those stack frames are just panic machinery; they don't give any information about the crash at all. The first interesting frame is this:

wgpu_hal::dx12::D3D12Lib::create_device(enum2$<wgpu_hal::auxil::dxgi::factory::DxgiAdapter>*, windows::lib::Win32::Graphics::Direct3D::D3D_FEATURE_LEVEL)
third_party/rust/wgpu-hal/src/dx12/mod.rs:184

What's interesting is that we see in frame 15 that the GPU process has received an InstanceRequestAdapter message:

mozilla::webgpu::WebGPUParent::RecvInstanceRequestAdapter(mozilla::dom::GPURequestAdapterOptions const&, unsigned long long, std::function<void (mozilla::ipc::ByteBuf&&)>&&)
dom/webgpu/ipc/WebGPUParent.cpp:415

It does make sense that visiting about:support might try to create an adapter, because it does try to report the characteristics of the default and fallback adapters. The question is why this would crash.

Comment 3

[Ashley Hale [:ahale]]

While my STR reliably produce a GPU process crash, I'm pretty sure this bug is just WGPU complaining about the already-on-fire GPU process, not causing it.

Comment 4

[Ashley Hale [:ahale]]

I discovered the trigger - I followed this guide at one point https://devblogs.microsoft.com/pix/debugging-d3d11-apps-using-d3d11on12/ when trying to debug with PIX some weeks ago and it seems to persist across reboots, originally in my experiments it seemed like it did not so I assumed it had returned to default, but D3D11on12 was still forced on when I checked today, turning it off caused the crash to go away. D3D11on12 seems to work for almost all situations but something about visiting youtube in Firefox 141 causes problems with it, and it's not a media issue, but I haven't figured out what the issue is.

Comment 5

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

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

• Top 5 GPU process crashes on release

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

For more information, please visit BugBot documentation.

Comment 6

[Jim Blandy :jimb]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #5)

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

• Top 5 GPU process crashes on release

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

For more information, please visit BugBot documentation.

This signature is overly broad, I've filed a bug to ignore those frames: https://github.com/mozilla-services/socorro/pull/7044

Comment 7

[Erich Gubler [:ErichDonGubler] (he/him)]

Updated the crash signature to match the one mentioned in the description.

Comment 8

[Jim Blandy :jimb]

The next step here would be to set D3D11on12 and see if WebGPU is entirely dead on arrival.

Assuming that is the case, these crashes are from our deliberate device-loss-as-crash panic. We could simply return the failure to content instead, if we can distinguish the D3D11on12 case from others.

If D3D11on12 is not widely used, we might consider treating WebGPU as blocklisted when D3D11on12 is enabled.