Skip to content
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

Closed
neocturne opened this issue Aug 1, 2022 · 17 comments
Closed

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

neocturne opened this issue Aug 1, 2022 · 17 comments
Labels
A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior O-Linux Specific to the Linux desktop operating system

Comments

@neocturne
Copy link
Contributor

neocturne commented Aug 1, 2022

Bevy version

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 Bevy UI example does not exit when window is closed. #5384 look similar, but not the same - my issue doesn't involve WinitSettings::desktop_app(), and therefore the workaround described in Bevy UI example does not exit when window is closed. #5384 (comment) doesn't help.
@neocturne neocturne added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Aug 1, 2022
@nicopap
Copy link
Contributor

nicopap commented Aug 1, 2022

Seems to be duplicate of #1908

@neocturne
Copy link
Contributor Author

neocturne commented Aug 1, 2022

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.

@alice-i-cecile alice-i-cecile added A-Windowing Platform-agnostic interface layer to run your app in O-Linux Specific to the Linux desktop operating system and removed S-Needs-Triage This issue needs to be labelled labels Aug 1, 2022
@nicopap
Copy link
Contributor

nicopap commented Aug 1, 2022

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
Copy link
Contributor Author

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

@jeffparsons
Copy link

jeffparsons commented Aug 8, 2022

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
Copy link

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

Indy2222 added a commit to DigitalExtinction/Game that referenced this issue Aug 10, 2022
This unfortunately introduces a bug: the app keeps running even after
all windows are closed bevyengine/bevy#5524
Indy2222 added a commit to DigitalExtinction/Game that referenced this issue Aug 10, 2022
This unfortunately introduces a bug: the app keeps running even after
all windows are closed
bevyengine/bevy#5524 (#184)
Indy2222 added a commit to DigitalExtinction/Game that referenced this issue Aug 10, 2022
This unfortunately introduces a bug: the app keeps running even after
all windows are closed
bevyengine/bevy#5524 (#184)
@xytis
Copy link

xytis commented Aug 17, 2022

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
  • aed3232 (cargo run --example empty_defaults -> make fullscreen, does not exit afterwards)

@nicopap
Copy link
Contributor

nicopap commented Aug 18, 2022

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@neocturne neocturne reopened this Aug 19, 2022
@neocturne
Copy link
Contributor Author

... or so I thought. The issue doesn't occur with my reduced test from #5524 (comment) anymore, but with the full DefaultPlugins it still happens. I'll investigate which plugin is responsible for the differing behavior.

@neocturne
Copy link
Contributor Author

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 (681c9c6) and v0.8.1 exhibit the same behavior as far as I can tell.

@ppearson
Copy link

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
Copy link

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
Copy link

any news? I'm facing this problem

@alice-i-cecile
Copy link
Member

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
Copy link
Contributor

nicopap commented Feb 23, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior O-Linux Specific to the Linux desktop operating system
Projects
None yet
Development

No branches or pull requests

8 participants