2D examples crash on exit with "Couldn't get swap chain texture" #11734
Comments
spectria-limina
added
C-Bug
|
This stack trace is pretty cursed, with the nested |
rparrett
added
A-Rendering
|
I bet it's because we're not waiting for the render thread to finish before cleaning up the window. We probably need to add a drop check that if the render thread isn't on the main thread we should wait for the render world to be sent back before dropping the render world channels. |
|
Could someone test if #11737 helps with this issue? |
|
Unfortunately, I'm still getting the same issue. |
|
hmm, I wonder if the swap chain is already destroyed when the resource is dropped. Might need to prevent render from being run again if we're exiting the app. |
|
does this branch fix this issue https://github.com/hymm/bevy/tree/no-render-if-app-exit? |
2024-02-07T07:19:09.357857Z INFO bevy_winit::system: Closing window 0v1
exiting early
thread 'Compute Task Pool (12)' panicked at crates/bevy_render/src/view/window/mod.rs:372:21:
Couldn't get swap chain texture, operation unrecoverable: The swap chain has been lost and needs to be recreated
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_render::view::window::prepare_windows`!
friz64@arch ~/D/r/bevy ((0fb0f3f2))> git diff
diff --git a/crates/bevy_render/src/pipelined_rendering.rs b/crates/bevy_render/src/pipelined_rendering.rs
index 86acfe37c..805603a97 100644
--- a/crates/bevy_render/src/pipelined_rendering.rs
+++ b/crates/bevy_render/src/pipelined_rendering.rs
@@ -180,6 +180,7 @@ fn update_rendering(app_world: &mut World, _sub_app: &mut App) {
// dont run render if app exit has been sent
if let Some(app_exit) = app_world.get_resource::<Events<AppExit>>() {
if !app_exit.is_empty() {
+ println!("exiting early");
return;
}
}The branch gets taken, but it still panics. |
|
weird. 2 possibilities: either the prepare windows is panicking for render run before app exit is sent or it's taking more than 2 ticks for the app to exit, since events only live for 2 frames. Could you add a println! after the 2 if's and see if it logs something after the "exiting early"? |
It does not log something. |
|
That means it's most likely the first option, which I'm not sure how to fix yet. |
|
It now panics twice on the main branch, see: #11811 (comment) Also, I got curious and tried directly running it in an X11 session (so, without XWayland) to see if it would behave differently, and indeed, it doesn't panic, but this error is printed instead: I'm not sure if this is really related, as this has been reported (twice?) before #11660 got merged:
So it might just be that the panic caused by #11660 only happens when running through XWayland. Oh how I love all this. Big headache. |
|
Seems like this issue ended up in |
WHY WIP: `_setup_camera` commented out for the moment because we observed the error mentioned in the comment (bevyengine/bevy#11734). With `do_nothing`, we get this: ``` 2024-03-28T11:58:43.553731Z ERROR log: X11 error: XError { description: "BadWindow (invalid Window parameter)", error_code: 3, request_code: 148, minor_code: 1, } 2024-03-28T11:58:43.567517Z ERROR bevy_winit: winit event loop returned an error: os error at /home/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/linux/x11/mod.rs:427: Xlib error: X error: BadWindow (invalid Window parameter) (code: 3, request code: 148, minor code: 1) ```
|
Hi there, I ran into the same issue and noticed an interesting difference in behaviour: I got the panic specifically when trying to add a camera to the Startup system: When I instead replace the Maybe that second error is also unwanted, not sure (every single GUI application I've ever seen seems to throw errors regularly when running normal) but at least it's something else; hope that helps in tracking stuff down! :) |
This doesn't do anything useful. Commit just kept around in case I need to revisit this. `_setup_camera` commented out for the moment because we observed the error mentioned in the comment (bevyengine/bevy#11734). With `do_nothing`, we get this: ``` 2024-03-28T11:58:43.553731Z ERROR log: X11 error: XError { description: "BadWindow (invalid Window parameter)", error_code: 3, request_code: 148, minor_code: 1, } 2024-03-28T11:58:43.567517Z ERROR bevy_winit: winit event loop returned an error: os error at /home/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.15/src/platform_impl/linux/x11/mod.rs:427: Xlib error: X error: BadWindow (invalid Window parameter) (code: 3, request code: 148, minor code: 1) ```
|
We already identified the issue for a while and #12524 is waiting for review. Until then a workaround is disabling pipelined rendering: |
… using pipelined rendering (#12978) # Objective A `RawWindowHandle` is only valid as long as the window it was retrieved from is alive. Extend the lifetime of the window, so that the `RawWindowHandle` doesn't outlive it, and bevy doesn't crash when closing a window a pipelined renderer is drawing to. - Fix #11236 - Fix #11150 - Fix #11734 - Alternative to / Closes #12524 ## Solution Introduce a `WindowWrapper` that takes ownership of the window. Require it to be used when constructing a `RawHandleWrapper`. This forces windowing backends to store their window in this wrapper. The `WindowWrapper` is implemented by storing the window in an `Arc<dyn Any + Send + Sync>`. We use dynamic dispatch here because we later want the `RawHandleWrapper` to be able dynamically hold a reference to any windowing backend's window. But alas, the `WindowWrapper` itself is still practically invisible to windowing backends, because it implements `Deref` to the underlying window, by storing its type in a `PhantomData`. --- ## Changelog ### Added - Added `WindowWrapper`, which windowing backends are now required to use to store their underlying window. ### Fixed - Fixed a safety problem which caused crashes when closing bevy windows when using pipelined rendering. ## Migration Guide - Windowing backends now need to store their window in the new `WindowWrapper`.
Bevy version
main, commit 2a1ebc4
[Optional] Relevant system information
What you did
cargo run --example spriteWhat went wrong
Everything runs fine until I close the window, then:
The text was updated successfully, but these errors were encountered: