-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
The right combination of SubApp, refresh rate, and AppExit event causes a panic half the time #9543
Comments
I got the error message
on main |
thread '<unnamed>' panicked at 'The TimeSender channel should always be empty during render. You might need to add the bevy::core::time_system to your app.: "Disconnected(..)"', F:\projects\bevy-fork\bevy\crates\bevy_render\src\renderer\mod.rs:91:44 The above should be fixed by ignoring disconnected errors from the time channel in the render app. The original issue is a bit harder to fix. It's due to the render world being dropped on the render thread during shutdown when it can only be dropped on the main thread. To fix this the main app should wait for the render thread to send back the render world before ending, but I think that might be a pain to implement as bevy's story around cleaning up resources on shutdown isn't the greatest. It might be better to wait for #9122 which would allow dropping the render world on another thread. |
One reason not to wait for removing non-send resources is that dropping on the wrong thread is potentially UB. I think we avoid any UB currently because the non-send data in the render world is just a marker without any special needs for where it is dropped. An option for fixing this might be to wrap the channels in the main world with a drop impl that will wait for the render world to come back if it's in another thread. We'd need to make sure that it handles panics in the render world correctly. |
# Objective - sometimes when bevy shuts down on certain machines the render thread tries to send the time after the main world has been dropped. - fixes an error mentioned in a reply in #9543 --- ## Changelog - ignore disconnected errors from the time channel.
# Objective - sometimes when bevy shuts down on certain machines the render thread tries to send the time after the main world has been dropped. - fixes an error mentioned in a reply in bevyengine#9543 --- ## Changelog - ignore disconnected errors from the time channel.
# Objective - sometimes when bevy shuts down on certain machines the render thread tries to send the time after the main world has been dropped. - fixes an error mentioned in a reply in bevyengine#9543 --- ## Changelog - ignore disconnected errors from the time channel.
What you did
Using a specific combination of
SubApp
,ScheduleRunnerPlugin
, and issuing anAppExit
event, I can get bevy to sometimes panic. It doesn't happen 100% of the time—sometimes it exits correctly. A few executions ofcargo run
is usually enough to reproduce the bug.Bevy version
Minimal example:
The only dependency is
bevy = "0.11.2"
.What went wrong
Bevy sometimes runs correctly, and sometimes panics. The issue can usually be reproduced by running
cargo run
under 5 times.When the app exits correctly, the output is:
When the app panics, the output is:
The expected behavior is never panicking.
My Rust info:
My OS info:
My adapter info:
Extra notes
The issue appears to be related to sub worlds and/or pipelined rendering.
On bevy
0.11
, the same issue occurs, but the error message is different:The text was updated successfully, but these errors were encountered: