Wgpu: Unexpected panic in `command_encoder_end_render_pass`

[gretchenfrage]

Description
I experienced a wgpu panic in code that typically works. Unfortunately the problem seems to be non-deterministic, probably stemming from my use of rayon. This also appears to be rare, I have been running the program on a loop but the bug has yet to re-occur.

Repro steps
Unfortunately I myself have not been able to reproduce this.

Extra materials
The panic backtrace:

thread '<unnamed>' panicked at 'extent state Extent { width: 1, height: 1, depth: 1 } must match extent from view Extent { width: 0, height: 0, depth: 1 }', C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.6.0\src\backend\direct.rs:1323:35
stack backtrace:
   0: backtrace::backtrace::trace_unsynchronized
             at C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.46\src\backtrace\mod.rs:66
   1: std::sys_common::backtrace::_print_fmt
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libstd\sys_common\backtrace.rs:78
   2: std::sys_common::backtrace::_print::{{impl}}::fmt
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libstd\sys_common\backtrace.rs:59
   3: core::fmt::write
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libcore\fmt\mod.rs:1076
   4: std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libstd\io\mod.rs:1537
   5: std::sys_common::backtrace::_print
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libstd\sys_common\backtrace.rs:62
   6: std::sys_common::backtrace::print
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libstd\sys_common\backtrace.rs:49
   7: std::panicking::default_hook::{{closure}}
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libstd\panicking.rs:198
   8: std::panicking::default_hook
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libstd\panicking.rs:217
   9: std::panicking::rust_panic_with_hook
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libstd\panicking.rs:526
  10: std::panicking::begin_panic_handler
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libstd\panicking.rs:437
  11: std::panicking::begin_panic_fmt
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libstd\panicking.rs:391
  12: wgpu::backend::direct::{{impl}}::unwrap_pretty::{{closure}}<tuple<>,wgpu_core::command::render::RenderPassError>
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.6.0\src\backend\direct.rs:1323
  13: wgpu::backend::direct::{{impl}}::command_encoder_end_render_pass
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.6.0\src\backend\direct.rs:1237
  14: core::ptr::drop_in_place
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\src\libcore\ptr\mod.rs:184
  15: game::graphics::draw_blocks::DrawBlocks::draw
             at \192.168.1.15\phoenix\pipeland\game\src\graphics\draw_blocks\mod.rs:112
  16: game::graphics::Graphics::draw
             at \192.168.1.15\phoenix\pipeland\game\src\graphics\mod.rs:175
  17: game::{{impl}}::run
             at \192.168.1.15\phoenix\pipeland\game\src\main.rs:207
  18: shred::system::{{impl}}::run_now<game::Draw>
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\shred-0.10.2\src\system.rs:140
  19: shred::dispatch::stage::{{impl}}::execute::{{closure}}
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\shred-0.10.2\src\dispatch\stage.rs:111
  20: core::ops::function::impls::{{impl}}::call_mut
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\src\libcore\ops\function.rs:253
  21: core::slice::{{impl}}::for_each
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\src\libcore\slice\mod.rs:3607
  22: rayon::iter::for_each::{{impl}}::consume_iter
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-1.4.1\src\iter\for_each.rs:55
  23: rayon::iter::plumbing::Producer::fold_with
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-1.4.1\src\iter\plumbing\mod.rs:110
  24: rayon::iter::plumbing::bridge_producer_consumer::helper<rayon::slice::IterMutProducer<arrayvec::ArrayVec<[alloc::boxed::Box<RunNow>; 5]>>,rayon::iter::for_each::ForEachConsumer<closure-0>>
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-1.4.1\src\iter\plumbing\mod.rs:438
  25: rayon::iter::plumbing::bridge_producer_consumer
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-1.4.1\src\iter\plumbing\mod.rs:397
  26: rayon::iter::plumbing::bridge::{{impl}}::callback<rayon::iter::for_each::ForEachConsumer<closure-0>,mut arrayvec::ArrayVec<[alloc::boxed::Box<RunNow>; 5]>*,rayon::slice::IterMutProducer<arrayvec::ArrayVec<[alloc::boxed::Box<RunNow>; 5]>>>
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-1.4.1\src\iter\plumbing\mod.rs:373
  27: rayon::slice::{{impl}}::with_producer
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-1.4.1\src\slice\mod.rs:854
  28: rayon::iter::plumbing::bridge
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-1.4.1\src\iter\plumbing\mod.rs:357
  29: rayon::slice::{{impl}}::drive_unindexed
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-1.4.1\src\slice\mod.rs:830
  30: rayon::iter::for_each::for_each
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-1.4.1\src\iter\for_each.rs:12
  31: rayon::iter::ParallelIterator::for_each
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-1.4.1\src\iter\mod.rs:369
  32: shred::dispatch::stage::Stage::execute
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\shred-0.10.2\src\dispatch\stage.rs:109
  33: rayon_core::job::{{impl}}::execute<rayon_core::latch::LockLatch*,closure-0,tuple<>>
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-core-1.8.1\src\job.rs:119
  34: rayon_core::job::JobRef::execute
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-core-1.8.1\src\job.rs:59
  35: rayon_core::registry::WorkerThread::execute
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-core-1.8.1\src\registry.rs:753
  36: rayon_core::registry::WorkerThread::wait_until_cold
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-core-1.8.1\src\registry.rs:730
  37: rayon_core::registry::WorkerThread::wait_until
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-core-1.8.1\src\registry.rs:704
  38: rayon_core::registry::main_loop
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-core-1.8.1\src\registry.rs:837
  39: rayon_core::registry::ThreadBuilder::run
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-core-1.8.1\src\registry.rs:56
  40: rayon_core::registry::{{impl}}::spawn::{{closure}}
             at C:\Users\Phoenix Kahlo\.cargo\registry\src\github.com-1ecc6299db9ec823\rayon-core-1.8.1\src\registry.rs:101
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Platform

• wgpu 0.6.0
• windows 10 home 10.0.19041 build 19041
• RTX 2070

[kvark]

Please post the call stack and the panic message.

[kvark]

Extent { width: 0, height: 0, depth: 1 } sounds very concerning

[gretchenfrage]

Extent { width: 0, height: 0, depth: 1 } sounds very concerning

Indeed. I wonder if my rayon-related stuff was a false herring, and this was actually the operating system placing the window into some sort of minimized state and assigning it dimensions of <0, 0>, triggering the crash?

[kvark]

Yes, this sounds much more likely

[cwfitzgerald]

Going to mark this as a dupe of #1026 as that seems like the likely explanation.