Manually running a schedule in a sub-world hangs

[Bytekeeper]

Bevy version

0.11.3

What you did

I tried to run the main schedule in a "sub-world". The following demo program should terminate, but as long as the "sub-world" contains a system, it will hang. (Please note that in a more elaborate example some systems might even run before it hangs)

use bevy::app::{AppExit, MainSchedulePlugin};
use bevy::prelude::*;

#[derive(Resource)]
pub struct SubWorld(World);

fn call_sub_app(mut world: ResMut<SubWorld>) {
    world.0.run_schedule(Main);
}

fn main() {
    let mut sub_app = App::empty();
    sub_app
        .add_plugins(MainSchedulePlugin)
        // Without systems, the app will exit immediately
        .add_systems(Update, || ());
    sub_app.finish();
    sub_app.cleanup();
    let world = sub_app.world;
    let mut app = App::empty();
    app.add_plugins(MainSchedulePlugin)
        .add_systems(Update, call_sub_app)
        .insert_resource(SubWorld(world));
    app.world.send_event(AppExit);
    app.run();
}

What went wrong

I expected the inner run_schedule to run and complete. After that, the outer system should continue (and terminate).
Instead it hangs, I assume there's a deadlock (here's an excerpt from GDB):

#0  0x00007fcd4b50ed6d in syscall () from /usr/lib/libc.so.6
#1  0x000055cabc4690f1 in std::sys::unix::futex::futex_wait ()
    at library/std/src/sys/unix/futex.rs:62
#2  std::sys::unix::locks::futex_condvar::Condvar::wait_optional_timeout ()
    at library/std/src/sys/unix/locks/futex_condvar.rs:49
#3  std::sys::unix::locks::futex_condvar::Condvar::wait ()
    at library/std/src/sys/unix/locks/futex_condvar.rs:33
#4  0x000055cabc414ba2 in std::sync::condvar::Condvar::wait<()> (
    self=0x55cabc5d88a0, guard=...)
    at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/sync/condvar.rs:191
#5  0x000055cabc417b8f in parking::Inner::park (self=0x55cabc5d8890, timeout=...)
    at src/lib.rs:358
#6  0x000055cabc4178d7 in parking::Parker::park (self=0x7fcd4b7f9c20)
    at src/lib.rs:119
#7  0x000055cabc31f50d in futures_lite::future::block_on::{closure#0}<alloc::vec::Vec<(), alloc::alloc::Global>, bevy_tasks::task_pool::{impl#2}::scope_with_executor_inner::{async_block_env#0}<bevy_ecs::schedule::executor::multi_threaded::{impl#2}::run::{closure_env#1}, ()>> (cache=0x7fcd4b7f9c18)
    at /home/dante/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-lite-1.13.0/src/future.rs:91
#8  0x000055cabc3344db in std::thread::local::LocalKey<core::cell::RefCell<(parking::Parker, core::task::wake::Waker)>>::try_with<core::cell::RefCell<(parking::Parker, core::task::wake::Waker)>, futures_lite::future::block_on::{closure_env#0}<alloc::vec::Vec<(), alloc::alloc::Global>, bevy_tasks::task_pool::{impl#2}::scope_with_executor_inner::{async_block_env#0}<bevy_ecs::schedule::executor::multi_threaded::{impl#2}::run::{closure_env#1}, ()>>, alloc::vec::Vec<(), alloc::alloc::Global>> (
    self=0x55cabc4f8590, f=...)
    at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/thread/local.rs:270
#9  0x000055cabc333932 in std::thread::local::LocalKey<core::cell::RefCell<(parking::Parker, core::task::wake::Waker)>>::with<core::cell::RefCell<(parking::Parker, core::task::wake::Waker)>, futures_lite::future::block_on::{closure_env#0}<alloc::vec::Vec<(), alloc::alloc::Global>, bevy_tasks::task_pool::{impl#2}::scope_with_executor_inner::{async_block_env#0}<bevy_ecs::schedule::executor::multi_threaded::{impl#2}::run::{closure_env#1}, ()>>, alloc::vec::Vec<(), alloc::alloc::Global>> (
    self=0x55cabc4f8590, f=...)
    at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/thread/local.rs:246
#10 0x000055cabc31f2a9 in futures_lite::future::block_on<alloc::vec::Vec<(), alloc::alloc::Global>, bevy_tasks::task_pool::{impl#2}::scope_with_executor_inner::{async_block_env#0}<bevy_ecs::schedule::executor::multi_threaded::{impl#2}::run::{closure_env#1}, ()>> (future=...)

[hymm]

can you do cargo tree and see if async_executor is at 1.5.4? If it's that or 1.5.3 can you try pinning to 1.5.1 cargo update -p async-executor --precise 1.5.1.

[Bytekeeper]

It's at 1.5.4:

cargo tree | rg async-executor
        │   │   │   │   ├── async-executor v1.5.4

Pinning it to 1.5.1 seems to resolve the issue!

[hymm]

async-executor made some changes to improve performance recently, but it's likely causing problems.

It might also be possible that the changes re-exposed this bug that we worked around before #7825 (comment).

[maniwani]

I encountered this in #9122. Examples with state transitions (like alien_cake_addict) just froze, but pinning async-executor to version 1.5.1 resolves it.

[hymm]

async-executor rolled back the change that was causing this and released 1.6.0. So this should be fixed, but I haven't tested yet.

[hymm]

The cause of this (queueing task to local queue) was completely rolled back in async executor.