-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Stack overflow with ambiguity detection and .run_if(in_state(...))
#9641
Comments
Can confirm the same problem on linux |
I can't reproduce on main branch, so it might have been fixed already. Can someone else test main to confirm? |
Same for me; main works without problems |
Yes it does seem to be fixed on the main branch (should've checked before probably...). Closing. |
I bisected this back to #9260. If I revert that change and run the above code it still stack overflows. Since that change was just moving systems around, the problem likely still exists on main too. Will try and see if I can come up with a better minimal reproduction. |
use bevy::prelude::*;
fn main() {
let mut schedule = Schedule::default();
fn exclusive(_world: &mut World) {}
fn dummy() {}
schedule.set_build_settings(bevy::ecs::schedule::ScheduleBuildSettings {
ambiguity_detection: bevy::ecs::schedule::LogLevel::Error,
..Default::default()
});
schedule.add_systems((exclusive, (dummy, dummy).run_if(|| true)));
schedule.initialize(&mut World::new()).unwrap();
} This stack overflows. Probably has something to do with anonymous system sets and exclusive systems. |
This turned out to be a problem with getting an anonymous system sets name when the report_sets settings was true. See above PR for more details. |
# Objective - Fixes #9641 - Anonymous sets are named by their system members. When `ScheduleBuildSettings::report_sets` is on, systems are named by their sets. So when getting the anonymous set name this would cause an infinite recursion. ## Solution - When getting the anonymous system set name, don't get their system's names with the sets the systems belong to. ## Other Possible solutions - An alternate solution might be to skip anonymous sets when getting the system's name for an anonymous set's name.
# Objective - Fixes bevyengine#9641 - Anonymous sets are named by their system members. When `ScheduleBuildSettings::report_sets` is on, systems are named by their sets. So when getting the anonymous set name this would cause an infinite recursion. ## Solution - When getting the anonymous system set name, don't get their system's names with the sets the systems belong to. ## Other Possible solutions - An alternate solution might be to skip anonymous sets when getting the system's name for an anonymous set's name.
Bevy version
bevy = "0.11.2"
[Optional] Relevant system information
What you did
Minimal example:
What went wrong
thread 'main' has overflowed its stack
upon running.Additional information
Note that using
distributive_run_if
seems to fix the problem. Also adding just one system (i.e.dummy_system.run_if(in_state(DummyState::Foo))
does not exhibit the problem. Problem happens even if different systems are used, the fact that it's the same system in the tuple is unrelated.Only confirmed on Windows. Would be great if someone with a Linux/Mac machine, could confirm/deny if this happens on other platforms.
The text was updated successfully, but these errors were encountered: