-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Process keeps running after window has been closed [Linux Xwayland] #5524
Comments
Seems to be duplicate of #1908 |
My issue was introduced somewhere between Bevy 0.7 and 0.8, so I believe that these are different issues. I have edited the issue description to mention this fact. |
Have you tried the workaround? Does it solve it for you? This would really help understand if it's a different kind of issue or the same. :) In my experience, the issues only showed occasionally pre 0.8, but on 0.8 it's pretty much all the time. |
The workaround from #1908 doesn't have any effect for me. |
I see this, too:
It also happens without the gamepad connected:
EDIT: OS info:
|
Looks like a race condition. if i add fn sleep_for_hundred_millis_system() {
let hundred_millis = time::Duration::from_millis(100);
thread::sleep(hundred_millis);
} then the application exits with the message:
Without "sleep system" - process keeps running after window has been closed |
This unfortunately introduces a bug: the app keeps running even after all windows are closed bevyengine/bevy#5524
This unfortunately introduces a bug: the app keeps running even after all windows are closed bevyengine/bevy#5524 (#184)
This unfortunately introduces a bug: the app keeps running even after all windows are closed bevyengine/bevy#5524 (#184)
In addition, the same symptoms appear on:
Minimal reproduction: fn main() {
let mut app = App::new();
app.insert_resource(WindowDescriptor {
mode: WindowMode::BorderlessFullscreen,
..default()
});
app.add_plugins(DefaultPlugins);
app.add_system(bevy::window::close_on_esc);
app.run();
} Bevy version:
|
Can someone reproduce this without the My hunch is that it's an interaction between bevy's handling of frame buffer and how X11 expect it to be done. |
This seems to be the minimal App that displays a window and doesn't print lots of warnings about missing labels: fn main() {
let mut app = bevy::app::App::new();
app.add_plugin(bevy::log::LogPlugin::default());
app.add_plugin(bevy::core::CorePlugin::default());
app.add_plugin(bevy::time::TimePlugin::default());
app.add_plugin(bevy::transform::TransformPlugin::default());
app.add_plugin(bevy::input::InputPlugin::default());
app.add_plugin(bevy::window::WindowPlugin::default());
app.add_plugin(bevy::asset::AssetPlugin::default());
app.add_plugin(bevy::winit::WinitPlugin::default());
app.add_plugin(bevy::render::RenderPlugin::default());
app.run();
} With this list of plugins, the behavior is unchanged, the process does not exit. Without the render plugin, the window is never displayed, so I can't check what would happen when the window is closed... |
I just updated to Bevy v0.8.1 and found that this has been fixed by #5558. |
... or so I thought. The issue doesn't occur with my reduced test from #5524 (comment) anymore, but with the full |
The issue has become less frequent with Bevy v0.8.1. The following program reproduces the issue roughly once every 5-10 runs: fn main() {
let mut app = bevy::app::App::new();
app.add_plugin(bevy::log::LogPlugin::default());
app.add_plugin(bevy::core::CorePlugin::default());
app.add_plugin(bevy::time::TimePlugin::default());
app.add_plugin(bevy::transform::TransformPlugin::default());
app.add_plugin(bevy::input::InputPlugin::default());
app.add_plugin(bevy::window::WindowPlugin::default());
app.add_plugin(bevy::asset::AssetPlugin::default());
app.add_plugin(bevy::winit::WinitPlugin::default());
app.add_plugin(bevy::render::RenderPlugin::default());
app.add_plugin(bevy::core_pipeline::CorePipelinePlugin::default());
app.add_plugin(bevy::sprite::SpritePlugin::default());
app.add_plugin(bevy::text::TextPlugin::default());
app.add_plugin(bevy::ui::UiPlugin::default());
app.add_plugin(bevy::pbr::PbrPlugin::default());
app.run();
} It's possible that the total number of systems has an influence: I've seen the issue with all plugins after Current main (681c9c6) and v0.8.1 exhibit the same behavior as far as I can tell. |
I'm also running into this issue on Linux Mint 20.3, with the Vulkan backend using a Intel(R) UHD Graphics 620. On another (Linux Mint 20.3) machine with a GTX 1070 with nVidia drivers, I don't get the issue at all. Before I upgraded to 0.8.1, I was always getting the issue, after upgrading to 0.8.1 it happens a lot less, but it still occasionally happens. I never recall seeing it at all with 0.7. |
Callstack of stuck process' thread0 after window is closed:
|
any news? I'm facing this problem |
This is resolved on |
According to discord users, this was solved with pipelined rendering (2027af4) FYI. For the little testing I did, it does look solved on main |
Bevy version
Relevant system information
I'm running a Wayland-based Linux system (swaywm) with Xwayland.
What you did
What went wrong
When closing the window, the process keeps running, instead of exiting as expected.
The same issue occurs with several other examples, as well as my own project that I'm porting to Bevy 0.8.
Additional information
--features wayland
is passed for native Wayland support, but I often see the messagebevy_winit: Skipped event for closed window: WindowId(00000000-0000-0000-0000-000000000000)
when I close the window with native Wayland.AppExit
event is generated as expected when the window is closed, and theevent_handler
handles it and setscontrol_flow
toControlFlow::Exit
. So it looks like the issue is actually caused by Winit; I wasn't able to get the examples in the winit repo to display a window on my system at all however (neither with Xwayland nor with native Wayland), so I'm unsure how to proceed with debugging.WinitSettings::desktop_app()
, and therefore the workaround described in Bevy UI example does not exit when window is closed. #5384 (comment) doesn't help.The text was updated successfully, but these errors were encountered: