Bevymark sometimes panics with "Called Result::unwrap() on an Err value"

[opstic]

Bevy version

Bevy Git (299bd37)

What you did

1. Run bevymark.
2. Close the app window.

What went wrong

• What were you expecting?

The app gracefully exits.

• What actually happened?

The app crashes due to the window.single() call after the window has been closed.

bevy/examples/stress_tests/bevymark.rs

Line 73 in 299bd37

let window = windows.single();

Additional information

Logs:

C:/Users/User/.cargo/bin/cargo.exe run --color=always --package bevy --example bevymark --release
    Finished release [optimized] target(s) in 1.02s
     Running `target\release\examples\bevymark.exe`
2023-01-28T20:27:12.022073Z  INFO bevy_winit::system: Creating new window "BevyMark" (0v0)
2023-01-28T20:27:12.339709Z  INFO bevy_render::renderer: AdapterInfo { name: "Intel(R) UHD Graphics 620", vendor: 32902, device: 22807, device_type: IntegratedGpu, driver: "Intel Corporation", driver_info: "Intel driver", backend: Vulkan }
2023-01-28T20:27:12.576022Z  WARN bevymark: This is a stress test used to push Bevy to its limit and debug performance issues. It is not representative of an actual game. It must be run in release mode using --release or it will be very slow.
2023-01-28T20:27:12.993780Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Windows 11 Pro for Workstations", kernel: "22621", cpu: "Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz", core_count: "4", memory: "7.9 GiB" }
2023-01-28T20:27:13.605354Z  INFO bevy diagnostic: frame_time                      :   12.304128ms (avg 9.301445ms)
2023-01-28T20:27:13.605426Z  INFO bevy diagnostic: fps                             :  103.083789   (avg 127.180158)
2023-01-28T20:27:13.605452Z  INFO bevy diagnostic: frame_count                     : 34.000000
2023-01-28T20:27:14.610938Z  INFO bevy diagnostic: frame_time                      :   26.047071ms (avg 35.430010ms)
2023-01-28T20:27:14.611030Z  INFO bevy diagnostic: fps                             :   73.854242   (avg 61.802481)
2023-01-28T20:27:14.611108Z  INFO bevy diagnostic: frame_count                     : 72.000000
2023-01-28T20:27:16.000367Z  INFO bevy diagnostic: frame_time                      :   99.458159ms (avg 59.436820ms)
2023-01-28T20:27:16.000422Z  INFO bevy diagnostic: fps                             :   18.614649   (avg 33.649745)
2023-01-28T20:27:16.000439Z  INFO bevy diagnostic: frame_count                     : 99.000000
2023-01-28T20:27:16.614072Z  INFO bevy diagnostic: frame_time                      :   52.782843ms (avg 64.720315ms)
2023-01-28T20:27:16.614144Z  INFO bevy diagnostic: fps                             :   21.400037   (avg 31.669169)
2023-01-28T20:27:16.614175Z  INFO bevy diagnostic: frame_count                     : 113.000000
2023-01-28T20:27:17.674446Z  INFO bevy diagnostic: frame_time                      :   85.278767ms (avg 68.694300ms)
2023-01-28T20:27:17.674517Z  INFO bevy diagnostic: fps                             :   11.852638   (avg 16.147101)
2023-01-28T20:27:17.674544Z  INFO bevy diagnostic: frame_count                     : 127.000000
thread 'Compute Task Pool (0)' panicked at 'called `Result::unwrap()` on an `Err` value: NoEntities("bevy_ecs::query::state::QueryState<&bevy_window::window::Window>")', examples/stress_tests/bevymark.rs:73:26
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/ef982929c0b653436a6ea6892a2a839fba7c8b57/library\std\src\panicking.rs:575
   1: core::panicking::panic_fmt
             at /rustc/ef982929c0b653436a6ea6892a2a839fba7c8b57/library\core\src\panicking.rs:64
   2: core::result::unwrap_failed
             at /rustc/ef982929c0b653436a6ea6892a2a839fba7c8b57/library\core\src\result.rs:1790
   3: bevy_ecs::system::query::Query<Q,F>::single
   4: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
   5: <bevy_ecs::system::function_system::FunctionSystem<In,Out,Param,Marker,F> as bevy_ecs::system::system::System>::run_unsafe
   6: async_task::raw::RawTask<F,T,S>::run
   7: <futures_lite::future::Or<F1,F2> as core::future::future::Future>::poll
   8: async_executor::Executor::run::{{closure}}
   9: std::thread::local::LocalKey<T>::with
  10: std::thread::local::LocalKey<T>::with
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', C:\Users\User\source\repos\bevy\crates\bevy_tasks\src\task_pool.rs:354:49
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/ef982929c0b653436a6ea6892a2a839fba7c8b57/library\std\src\panicking.rs:575
   1: core::panicking::panic_fmt
             at /rustc/ef982929c0b653436a6ea6892a2a839fba7c8b57/library\core\src\panicking.rs:64
   2: core::panicking::panic
             at /rustc/ef982929c0b653436a6ea6892a2a839fba7c8b57/library\core\src\panicking.rs:114
   3: bevy_tasks::thread_executor::ThreadExecutorTicker::tick::{{closure}}
   4: <futures_lite::future::Or<F1,F2> as core::future::future::Future>::poll
   5: bevy_ecs::system::system_param::assert_component_access_compatibility
   6: std::thread::local::LocalKey<T>::with
   7: bevy_tasks::task_pool::TaskPool::scope_with_executor_inner
   8: <bevy_ecs::schedule::executor_parallel::ParallelExecutor as bevy_ecs::schedule::executor::ParallelSystemExecutor>::run_systems
   9: <bevy_ecs::schedule::stage::SystemStage as bevy_ecs::schedule::stage::Stage>::run
  10: bevy_ecs::schedule::Schedule::run_once
  11: bevy_app::app::App::update
  12: winit::platform_impl::platform::event_loop::EventLoop<T>::run_return::{{closure}}
  13: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  14: winit::platform_impl::platform::event_loop::runner::EventLoopRunner<T>::register_window
  15: winit::platform_impl::platform::event_loop::runner::EventLoopRunner<T>::move_state_to
  16: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  17: winit::platform_impl::platform::event_loop::runner::EventLoopRunner<T>::catch_unwind
  18: winit::platform_impl::platform::event_loop::EventLoopThreadExecutor::execute_in_thread
  19: DispatchMessageW
  20: DispatchMessageW
  21: GetClassLongW
  22: KiUserCallbackDispatcher
  23: NtUserDispatchMessage
  24: DispatchMessageW
  25: winit::platform_impl::platform::event_loop::EventLoop<T>::run_return
  26: winit::platform_impl::platform::event_loop::EventLoop<T>::run
  27: <T as core::convert::Into<U>>::into
  28: <bevy_winit::WinitPlugin as bevy_app::plugin::Plugin>::build
  29: bevy_winit::winit_runner
  30: core::ops::function::Fn::call
  31: bevy_app::app::App::run
  32: <S as bevy_ecs::schedule::system_descriptor::IntoSystemDescriptor<Params>>::into_descriptor
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: process didn't exit successfully: `target\release\examples\bevymark.exe` (exit code: 101)

[rparrett]

Is this windows-OS-only? I can't reproduce.

I thought this was fixed by #7296

[mockersf]

I can reproduce easily on my mac by reducing the fixed time step here:

bevy/examples/stress_tests/bevymark.rs

Line 54 in 1a96d82

.with_run_criteria(FixedTimestep::step(0.2))

This is probably due to a strange interaction with stages and fixed time steps... A quick guess would be that if a fixed time step is replayed during the same run of the stage, the window was despawned during the first run and not available during the next runs. I think fixing this should wait for #7267

[rparrett]

I started noticing this in bevymark and bisected to e3cf5f8.

I can reliably reproduce this with:

AdapterInfo { name: "Apple M1 Max", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }

use bevy::{
    prelude::*,
    window::PresentMode,
    winit::{UpdateMode, WinitSettings},
};

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .insert_resource(WinitSettings {
            focused_mode: UpdateMode::Continuous,
            unfocused_mode: UpdateMode::Continuous,
        })
        .add_systems(Update, window)
        .run();
}

fn window(query: Query<&Window>) {
    let _window = query.single();
}

Which seems quite odd. Possible that this is a different bug than the one that existed at the time this issue was created.