1930015 - Crash in [@ core::result::unwrap_failed | wgpu_core::device::resource::Device::create_query_set]

Status: ASSIGNED

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

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/5973091f-b74b-4b7e-9401-159b20241106

MOZ_CRASH Reason:

called `Result::unwrap()` on an `Err` value: ResourceCreationFailed

Top 10 frames:

0  XUL  MOZ_Crash(char const*, int, char const*)  mfbt/Assertions.h:324
0  XUL  RustMozCrash  mozglue/static/rust/wrappers.cpp:18
1  XUL  mozglue_static::panic_hook  mozglue/static/rust/lib.rs:102
2  XUL  core::ops::function::Fn::call  library/core/src/ops/function.rs:79
3  XUL  <alloc::boxed::Box<F, A> as core::ops::function::Fn<Args>>::call  library/alloc/src/boxed.rs:2084
3  XUL  std::panicking::rust_panic_with_hook  library/std/src/panicking.rs:808
4  XUL  std::panicking::begin_panic_handler::{{closure}}  library/std/src/panicking.rs:674
5  XUL  std::sys::backtrace::__rust_end_short_backtrace  library/std/src/sys/backtrace.rs:168
6  XUL  rust_begin_unwind  library/std/src/panicking.rs:665
7  XUL  core::panicking::panic_fmt  library/core/src/panicking.rs:74

Only a single crash, but it is some kind of unhandled condition so I figured that I'd file it.

Comment 1

[Teodor Tanasoaia [:teoxoy]]

Erich, would you be able to look into this?

Comment 2

[Erich Gubler [:ErichDonGubler]]

I was able to reproduce this crash stack on my M1 MacBook Pro by running the following script:

const adapter = await navigator.gpu.requestAdapter()
const device = await adapter.requestDevice({ requiredFeatures: ["timestamp-query"] })
device.createQuerySet({ type: "timestamp", count: 8192 })

I feel safe in saying that this must be the issue, since count is really the only knob to turn in this API usage. It seems we're not correctly checking a platform limit of some sort. Perhaps the relevant one to apply is GPUSupportedLimits.maxBufferSize? :teoxoy and :jimb, do you have any ideas?

WGPU enforces a limit of 8192 queries, but it's not exposed in standard WebGPU/Firefox in any way. It's also a compile-time constant, which seems incorrect in the face of dynamic buffer size limitations.

Comment 3

[Erich Gubler [:ErichDonGubler]]

Reported upstream as wgpu#6504.

Comment 4

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

Set release status flags based on info from the regressing bug 1838729

Comment 5

[Erich Gubler [:ErichDonGubler]]

Filed a PR to resolve the crashing behavior (wgpu#6505). It doesn't resolve the upstream issue in that we should be avoiding provoking platform errors and return validation errors instead, but even an internal error in the WebGPU API is more tolerable than a crash.

I will remove the NIs for :teoxoy and :jimb, as I have repeated my prompt for information in the upstream issue.