-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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 sometimes keeps running after window is closed #839
Comments
I got a stacktrace with gdb:
|
I'm experiencing the exact same bug very consistently in one system (laptop with dual Intel + AMD GPU) after commit d5a7330. I have another system (single RTX 3070 GPU) where this doesn't happen. The more verbose logging output I enable the rarest to non-existent the problem is. This happens both on debug and release. Very rarely does this happen on the first run after a long compile, but then happens most of the time. This suggest some sort of race condition in wgpu. In the end I've set up a local copy of wgpu and traced this back to impl<G: GlobalIdentityHandlerFactory> Drop for Global<G> {
fn drop(&mut self) {
if !thread::panicking() {
tracing::info!("Dropping Global");
let mut surface_guard = self.surfaces.data.write();
tracing::info!("DEBUGGING ATTEMPT: this is logged");
// destroy hubs
#[cfg(vulkan)]
{
self.hubs.vulkan.clear(&mut *surface_guard, true);
}
#[cfg(metal)]
{
self.hubs.metal.clear(&mut *surface_guard, true);
}
#[cfg(dx12)]
{
self.hubs.dx12.clear(&mut *surface_guard, true);
}
#[cfg(dx11)]
{
self.hubs.dx11.clear(&mut *surface_guard, true);
}
#[cfg(gl)]
{
self.hubs.gl.clear(&mut *surface_guard, true);
}
tracing::info!("DEBUGGING ATTEMPT: hangs before this");
// destroy surfaces
for element in surface_guard.map.drain(..) {
if let Element::Occupied(surface, _) = element {
self.instance.destroy_surface(surface);
}
}
}
}
} |
As an additional detail, this seems to only happen in
Could you please check if this somehow matches your setup and/or any of the above workarounds "fix" this? |
I see something similar, so far only in release mode (couldn't reproduce in debug mode)
gdb backtrace:
|
This is the same as #1908 and gfx-rs/wgpu#1446 |
This issue seems similar to #5524 and #1908, which are now fixed. I assume this is also fixed. If anyone can reproduce in bevy 0.10.0, please speak up. It's probably a race condition, since it was "fixed" when pipelined rendering was introduced. But I simply can't reproduce while before it was fairly consistent, so I assume it's fully fixed 😛 |
Bevy version
b113809
Operating system & version
Ubuntu 20.04
What you did
But it doesn't always happen, so I'm not sure how to reproduce it, and also I don't know if it happens if I close the window with the window manager's button.
What you expected to happen
The process should have exited immediately after the AppExit event.
What actually happened
The window closed, but the process kept running in my terminal.
Hitting CTRL-C in my terminal still closed the process.
The text was updated successfully, but these errors were encountered: