Wgpu: Validate a buffer exists when used

Created on 24 Apr 2020  路  7Comments  路  Source: gfx-rs/wgpu

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.

Strack trace

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?

enhancement

Most helpful comment

Should this be closed now that #667 is merged?

All 7 comments

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?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

z2oh picture z2oh  路  13Comments

cwfitzgerald picture cwfitzgerald  路  20Comments

kvark picture kvark  路  11Comments

cloudhead picture cloudhead  路  15Comments

simast picture simast  路  15Comments