Threaded example panics on Linux

[ecton]

trafficstars

My engine that I based on rgx is panicing on linux. All of the examples work fine except the threaded example. Here's the backtrace:

thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `1`', /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:266:23
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1069
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1504
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:511
  11: rust_begin_unwind
             at src/libstd/panicking.rs:419
  12: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:373
  13: <wgpu_native::hub::Storage<T,I> as core::ops::index::Index<I>>::index
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/hub.rs:120
  14: wgpu_native::command::command_encoder_begin_render_pass::{{closure}}
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:266
  15: core::option::Option<T>::map
             at /home/ecton/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:456
  16: wgpu_native::command::command_encoder_begin_render_pass
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:264
  17: wgpu_command_encoder_begin_render_pass
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:739
  18: wgpu::CommandEncoder::begin_render_pass
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.4.0/src/lib.rs:1059
  19: rgx::core::Pass::begin
             at src/core/mod.rs:837
  20: rgx::core::Frame::pass
             at ./src/core/mod.rs:794
  21: threaded::main::{{closure}}
             at examples/threaded.rs:68
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

If I enable Vsync, the panic goes away both in the example and in my code. I attempted to investigate updating rgx to wgpu 0.5 to see if that would help, but there are significant API changes that I wasn't sure how to handle.

[ecton]

I should also point out that for me, this is not a major issue, but it does seem like a bug. I personally want Vsync, so this is not actually affecting me at this point in time, I just wanted to report it in case someone else runs into it.