Amazing work, thanks a lot for the WebGPU implementation!
I just encountered something when using an invalid / inexisting buffer resource. Basically, the resource isn't found when binding, creating a panic.
hread '<unnamed>' panicked at 'key not present', src/libcore/option.rs:1188:5
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:84
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:61
4: core::fmt::write
at src/libcore/fmt/mod.rs:1025
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1426
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:65
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:50
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:193
9: std::panicking::default_hook
at src/libstd/panicking.rs:210
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:471
11: rust_begin_unwind
at src/libstd/panicking.rs:375
12: core::panicking::panic_fmt
at src/libcore/panicking.rs:84
13: core::option::expect_failed
at src/libcore/option.rs:1188
14: core::option::Option<T>::expect
at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libcore/option.rs:348
15: <vec_map::VecMap<V> as core::ops::index::Index<usize>>::index
at /Users/davidpeicho/.cargo/registry/src/github.com-1ecc6299db9ec823/vec_map-0.8.1/src/lib.rs:818
16: <wgpu_core::hub::Storage<T,I> as core::ops::index::Index<I>>::index
at /Users/davidpeicho/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/6b0751f/wgpu-core/src/hub.rs:83
17: wgpu_core::track::ResourceTracker<S>::use_extend
at /Users/davidpeicho/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/6b0751f/wgpu-core/src/track/mod.rs:381
18: wgpu_core::device::<impl wgpu_core::hub::Global<G>>::device_create_bind_group
at /Users/davidpeicho/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/6b0751f/wgpu-core/src/device/mod.rs:1111
19: wgpu_device_create_bind_group
at src/device.rs:280
20: <unknown>
I guess the issue comes from this line.
Do you think it would be a good idea to assert this case and expose a clear error to the user?
Yeah it would be great to add an assert here with a clear error message.
In the future we'll replace most of these asserts with proper error handling as described in https://github.com/gpuweb/gpuweb/blob/a8d185887f172002876be4b2d0d2b0a29cb93670/design/ErrorHandling.md
Ok I see. In the meantime, I can add a simple PR maybe with an assert. I am not familiar with the codebase yet and an easy issue could be a good way to start learning it
Sounds good, that would be greatly appreciated!
@DavidPeicho thank you for filing! How are you using wgpu? is it via Python?
Hey @kvark, I am using it in C++ right now, using wgpu-native
You are using a buffer that you already destroyed. This isn't a typical error happening in wgpu: Rust enforces this at compile time, and Python and JS protect against this with GC. So this is a problem that only happens for C/C++ direct users.
Making the assertion nicer would still be appreciated :)
Should this be closed now that #667 is merged?
Most helpful comment
Should this be closed now that #667 is merged?