macos: app hangs after pressing window close button #13208
Labels
A-Windowing
Platform-agnostic interface layer to run your app in
C-Bug
An unexpected or incorrect behavior
O-MacOS
Specific to the MacOS (Apple) desktop operating system
Milestone
Comments
rparrett
added
C-Bug
|
@Friz64 any idea on how to fix? |
mockersf
added
A-Windowing
|
Ouch, sorry about this. No idea why my PR would cause this. I unfortunately can't debug this by myself as I don't have access to appropriate hardware at the moment. Best I can do right now is to do some research, in the hopes that I find something useful. But what we can always do is to put a |
|
I'm getting this when setting It looks like it's hanging before it creates the next surface texture after the previous was presented. After checking out the main branch from a week ago, we should additionally have the following logs after And
|
|
Odd. It seems the |
|
I'm a bit new to using a debugger, but it seems to be blocking on a Condvar? 
It occurs within bevy/crates/bevy_tasks/src/task_pool.rs Line 386 in 4083750 So it appears that something is not waking up the main thread. Perhaps the window |
|
There are probably better ways to debug, but I tested with this: impl Drop for RawHandleWrapper {
fn drop(&mut self) {
println!("Drop RawHandleWrapper: {}", Arc::strong_count(&self._window));
}
}And something similar for That shows a drop of a I'm not familiar enough with macOS APIs to know if there's any macOS-related reason this might happen. |
|
Ah. It looks like the drop impl for the So it's probably an issue that happens when the |
|
On macOS,
|
|
Yeah. it looks like the worker thread is hanging in While the main thread is blocked on bevy/crates/bevy_tasks/src/task_pool.rs Line 386 in 4083750 So I guess bevy is blocking the thread running |
tychedelia
added a commit
to tychedelia/bevy
that referenced
this issue
May 4, 2024
Fixes two issues related to bevyengine#13208. First, we ensure render resources for a window are always dropped first to ensure that the `winit::Window` always drops on the main thread when it is removed from `WinitWindows`. Previously, changes in bevyengine#12978 caused the window to drop in the render world, causing issues. We accomplish this by delaying despawning the window by a frame by inserting a marker component `ClosingWindow` that indicates the window has been requested to close and is in the process of closing. The render world now responds to the equivalent `WindowClosing` event rather than `WindowCloseed` which now fires after the render resources are guarunteed to be cleaned up. Secondly, fixing the above caused (revealed?) that additional events were being delivered to the the event loop handler after exit had already been requested: in my testing `RedrawRequested` and `LoopExiting`. This caused errors to be reported try to send an exit event on the close channel. There are two options here: - Guard the handler so no additional events are delivered once the app is exiting. I considered this but worried it might be confusing or bug prone if in the future someone wants to handle `LoopExiting` or some other event to clean-up while exiting. - Only send an exit signal if we are not already exiting. It doesn't appear to cause any problems to handle the extra events so this seems safer. Fixing this also appears to have fixed bevyengine#13231.
tychedelia
added a commit
to tychedelia/bevy
that referenced
this issue
May 4, 2024
Fixes two issues related to bevyengine#13208. First, we ensure render resources for a window are always dropped first to ensure that the `winit::Window` always drops on the main thread when it is removed from `WinitWindows`. Previously, changes in bevyengine#12978 caused the window to drop in the render world, causing issues. We accomplish this by delaying despawning the window by a frame by inserting a marker component `ClosingWindow` that indicates the window has been requested to close and is in the process of closing. The render world now responds to the equivalent `WindowClosing` event rather than `WindowCloseed` which now fires after the render resources are guarunteed to be cleaned up. Secondly, fixing the above caused (revealed?) that additional events were being delivered to the the event loop handler after exit had already been requested: in my testing `RedrawRequested` and `LoopExiting`. This caused errors to be reported try to send an exit event on the close channel. There are two options here: - Guard the handler so no additional events are delivered once the app is exiting. I considered this but worried it might be confusing or bug prone if in the future someone wants to handle `LoopExiting` or some other event to clean-up while exiting. - Only send an exit signal if we are not already exiting. It doesn't appear to cause any problems to handle the extra events so this seems safer. Fixing this also appears to have fixed bevyengine#13231.
tychedelia
added a commit
to tychedelia/bevy
that referenced
this issue
May 4, 2024
Fixes two issues related to bevyengine#13208. First, we ensure render resources for a window are always dropped first to ensure that the `winit::Window` always drops on the main thread when it is removed from `WinitWindows`. Previously, changes in bevyengine#12978 caused the window to drop in the render world, causing issues. We accomplish this by delaying despawning the window by a frame by inserting a marker component `ClosingWindow` that indicates the window has been requested to close and is in the process of closing. The render world now responds to the equivalent `WindowClosing` event rather than `WindowCloseed` which now fires after the render resources are guarunteed to be cleaned up. Secondly, fixing the above caused (revealed?) that additional events were being delivered to the the event loop handler after exit had already been requested: in my testing `RedrawRequested` and `LoopExiting`. This caused errors to be reported try to send an exit event on the close channel. There are two options here: - Guard the handler so no additional events are delivered once the app is exiting. I considered this but worried it might be confusing or bug prone if in the future someone wants to handle `LoopExiting` or some other event to clean-up while exiting. - Only send an exit signal if we are not already exiting. It doesn't appear to cause any problems to handle the extra events so this seems safer. Fixing this also appears to have fixed bevyengine#13231.
Merged
github-merge-queue bot
pushed a commit
that referenced
this issue
May 12, 2024
# Objective Fixes two issues related to #13208. First, we ensure render resources for a window are always dropped first to ensure that the `winit::Window` always drops on the main thread when it is removed from `WinitWindows`. Previously, changes in #12978 caused the window to drop in the render world, causing issues. We accomplish this by delaying despawning the window by a frame by inserting a marker component `ClosingWindow` that indicates the window has been requested to close and is in the process of closing. The render world now responds to the equivalent `WindowClosing` event rather than `WindowCloseed` which now fires after the render resources are guarunteed to be cleaned up. Secondly, fixing the above caused (revealed?) that additional events were being delivered to the the event loop handler after exit had already been requested: in my testing `RedrawRequested` and `LoopExiting`. This caused errors to be reported try to send an exit event on the close channel. There are two options here: - Guard the handler so no additional events are delivered once the app is exiting. I ~considered this but worried it might be confusing or bug prone if in the future someone wants to handle `LoopExiting` or some other event to clean-up while exiting.~ We are now taking this approach. - Only send an exit signal if we are not already exiting. ~It doesn't appear to cause any problems to handle the extra events so this seems safer.~ Fixing this also appears to have fixed #13231. Fixes #10260. ## Testing Tested on mac only. --- ## Changelog ### Added - A `WindowClosing` event has been added that indicates the window will be despawned on the next frame. ### Changed - Windows now close a frame after their exit has been requested. ## Migration Guide - Ensure custom exit logic does not rely on the app exiting the same frame as a window is closed.
|
Can this now be closed after #13236? |
|
works fine for me on macOS now 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bevy version
main, bisected to #12978
Relevant system information
What you did
cargo run --example spritecargo run --example buttonPress close button in top left corner of title bar.
What went wrong
App hangs instead of closing
The text was updated successfully, but these errors were encountered: