Process keeps running after window has been closed [Linux Xwayland]

[neocturne]

Bevy version

• 0.8
• main 6752c9c59b3b81168ea6607767cbb519e5127976

Relevant system information

I'm running a Wayland-based Linux system (swaywm) with Xwayland.

AdapterInfo { name: "AMD RADV RENOIR", vendor: 4098, device: 5686, device_type: IntegratedGpu, backend: Vulkan }

What you did

cargo run --example empty_defaults

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

• Bevy 0.7 did not exhibit this issue.
• The issue only occurs with Xwayland.
  • Exiting works fine when --features wayland is passed for native Wayland support, but I often see the message bevy_winit: Skipped event for closed window: WindowId(00000000-0000-0000-0000-000000000000) when I close the window with native Wayland.
  • I have not tested a native X11 system without Wayland.
• An AppExit event is generated as expected when the window is closed, and the event_handler handles it and sets control_flow to ControlFlow::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.
• The symptoms of #5384 look similar, but not the same - my issue doesn't involve WinitSettings::desktop_app(), and therefore the workaround described in https://github.com/bevyengine/bevy/issues/5384#issuecomment-1189707869 doesn't help.

[nicopap]

Seems to be duplicate of https://github.com/bevyengine/bevy/issues/1908

[neocturne]

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.

[nicopap]

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.

[neocturne]

The workaround from #1908 doesn't have any effect for me.

[jeffparsons]

I see this, too:

    Finished dev [optimized + debuginfo] target(s) in 0.09s
     Running `target/debug/grass`
2022-08-08T07:46:52.239760Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1    
2022-08-08T07:46:52.274356Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD RADV POLARIS10", vendor: 4098, device: 26591, device_type: DiscreteGpu, backend: Vulkan }
2022-08-08T07:46:52.623051Z  INFO gilrs_core::platform::platform::gamepad: Gamepad /dev/input/event9 (Thrustmaster Gamepad GP XID) connected.    
2022-08-08T07:46:52.624114Z  INFO bevy_input::gamepad: Gamepad { id: 0 } Connected

It also happens without the gamepad connected:

    Finished dev [optimized + debuginfo] target(s) in 0.09s
     Running `target/debug/grass`
2022-08-08T07:47:43.919353Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1    
2022-08-08T07:47:43.961366Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD RADV POLARIS10", vendor: 4098, device: 26591, device_type: DiscreteGpu, backend: Vulkan }

EDIT: OS info:

~/Projects/grass took 21s> uname -a
Linux prism 5.15.0-43-generic #46-Ubuntu SMP Tue Jul 12 10:30:17 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
~/Projects/grass> cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"

[workhackergamewin]

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:

INFO bevy_winit: Skipped event for closed window: WindowId(00000000-0000-0000-0000-000000000000)

Without "sleep system" - process keeps running after window has been closed

[xytis]

In addition, the same symptoms appear on:

2022-08-17T11:39:10.220248Z  INFO bevy_render::renderer: AdapterInfo { name: "Apple M1 Pro", vendor: 0, device: 0, device_type: IntegratedGpu, backend: Metal }

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:

• 0.8
• aed3232e (cargo run --example empty_defaults -> make fullscreen, does not exit afterwards)

[nicopap]

Can someone reproduce this without the bevy_render plugin?

My hunch is that it's an interaction between bevy's handling of frame buffer and how X11 expect it to be done.

[neocturne]

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...

[neocturne]

I just updated to Bevy v0.8.1 and found that this has been fixed by #5558.

[neocturne]

... or so I thought. The issue doesn't occur with my reduced test from https://github.com/bevyengine/bevy/issues/5524#issuecomment-1219915649 anymore, but with the full DefaultPlugins it still happens. I'll investigate which plugin is responsible for the differing behavior.

[neocturne]

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 CorePipelinePlugin commented out, but only once in 10s of runs. Having more plugins seems to make the issue more likely to occur.

Current main (681c9c6dc859be52565609e56ce9dc7f6f1c1f12) and v0.8.1 exhibit the same behavior as far as I can tell.

[ppearson]

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.

[ppearson]

Callstack of stuck process' thread0 after window is closed:

#0  __futex_abstimed_wait_common64 (private=128, cancel=true, abstime=0x0, op=265, expected=47597, 
    futex_word=0x7f8e567fc910) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common (cancel=true, private=128, abstime=0x0, clockid=0, expected=47597, 
    futex_word=0x7f8e567fc910) at ./nptl/futex-internal.c:87
#2  __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f8e567fc910, expected=47597, 
    clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=128) at ./nptl/futex-internal.c:139
#3  0x00007f8e8ca4b6a4 in __pthread_clockjoin_ex (threadid=140249313297984, thread_return=0x0, clockid=0, 
    abstime=0x0, block=<optimized out>) at ./nptl/pthread_join_common.c:105
#4  0x00007f8e619716ac in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_intel.so
#5  0x000055e513ca8151 in wgpu_hal::vulkan::instance::<impl wgpu_hal::Surface<wgpu_hal::vulkan::Api> for wgpu_hal::vulkan::Surface>::unconfigure ()
#6  0x000055e513206a8d in <wgpu_core::hub::Global<G> as core::ops::drop::Drop>::drop ()
#7  0x000055e51323cf13 in core::ptr::drop_in_place<wgpu_core::hub::Global<wgpu_core::hub::IdentityManagerFactory>>
    ()
#8  0x000055e51323e3ec in alloc::sync::Arc<T>::drop_slow ()
#9  0x000055e51323eba9 in alloc::sync::Arc<T>::drop_slow ()
#10 0x000055e51322ff81 in _ZN8bevy_ecs9component19ComponentDescriptor8drop_ptr17h519e89d3882ce662E.llvm.341166563434198279 ()
#11 0x000055e513fe86f6 in <bevy_ecs::storage::blob_vec::BlobVec as core::ops::drop::Drop>::drop ()

[Heraclito-Q-Saldanha]

any news? I'm facing this problem

[alice-i-cecile]

This is resolved on main, and will be published with 0.10's release. If you still encounter this problem after that, please comment and/or reopen the issue.

[nicopap]

According to discord users, this was solved with pipelined rendering (2027af4c54082007fed2091f112a11cb0bc5fc08) FYI. For the little testing I did, it does look solved on main