Stack overflow with large-ish Bundle spawn

[ejrh]

## Bevy version and features

Bevy main, since #20422 was merged in ad36585

Using "experimental_bevy_feathers" feature.

stacktrace.txt

[Optional] Relevant system information

Windows 11 64 bit. Standard Rustup setup.

stable-x86_64-pc-windows-msvc
cargo 1.88.0 (873a06493 2025-05-10)
(bug still happens with cargo 1.89.0 (c24e10642 2025-06-23))

What you did

Run the "feathers" example:

cargo r --example feathers --features="experimental_bevy_feathers"

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
     Running `target\debug\examples\feathers.exe`
2025-08-14T06:39:35.039573Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Windows 11 Home", kernel: "26100", cpu: "AMD Ryzen 9 9900X3D 12-Core Processor", core_count: "12", memory: "61.6 GiB" }
2025-08-14T06:39:35.260736Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon RX 7600", vendor: 4098, device: 29824, device_type: DiscreteGpu, driver: "AMD proprietary driver", driver_info: "25.6.1 (LLPC)", backend: Vulkan }
2025-08-14T06:39:35.500139Z  INFO bevy_render::batching::gpu_preprocessing: GPU preprocessing is fully supported on this device.
2025-08-14T06:39:35.522873Z  INFO bevy_winit::system: Creating new window feathers (0v0)

thread 'main' has overflowed its stack
error: process didn't exit successfully: `target\debug\examples\feathers.exe` (exit code: 0xc00000fd, STATUS_STACK_OVERFLOW)

I used "git bisect" to narrow down where the bug first occurs to commit ad36585.

What went wrong

Expecting: a nice "Feathers" example with various widgets I can play with.
Got: a stack overflow

Additional information

I was able to get a stack trace from the RustRover debugger, so skip my theorising if you like... Stack trace attached, updated for latest commit d95313b and to remove my printlns so the line numbers are more accurate,

stacktrace.txt

I don't think the color slider code added in this commit causes the problem, except insofar as the "impl Bundle" returned by demo_root has grown larger.

The problem does not occur in release mode, nor if I remove some of the nodes added in demo_root. Removing either all the newly-added color sliders, or all the pre-existing widgets and leaving the color sliders intact seems to work.

My theory would be either endless function recursion, or an excessive frame size in a function call. I am not an expert on Windows or Rust compilation, so I have mostly made progress by adding "println!" macros at various places. The setup system completes but another system set to run straight afterwards never gets to run:

...
app.add_systems(Startup, print_stuff.after(setup));
...

fn print_stuff() {
    println!("stuff!");     // this isn't printed
}

Adding more printing, it seems that all the individual commands are applied in apply_or_drop_queued, but then it's not clear if control ever returns to the caller. Maybe some Drop code runs and that's where it all goes wrong.

[ejrh]

#Starting to think it is simply the large stack frames -- perhaps with extra debugging stuff in debug mode, or simply less stuff optimised out -- versus Windows's 1 MB default stack size.

I looked at RSP when I had the stack trace open in the debugger. Some individual calls result in very large RSP changes. (I don't know if there's an automated way to check this for every line of the stack trace.)

__chkstk()
... another 10 or so calls before the stack overflow, several with quite big stack frames ...
0x00000052374bcad0 commands::impl$2::spawn::closure$0                      (38 kB jump)
0x00000052374c60f0 entity_command::impl$0::apply
0x00000052374c6140 command_handling::impl$3::with_entity::closure$0        (38 kB jump)
0x00000052374cf7e0 command::impl$0::apply
0x00000052374cf820 command_handling::impl$0::handle_error::closure$0        (38 kB jump;)
0x00000052374d8e90 command::impl$0::apply
0x00000052374d8ec0 command_queue::impl$4::push::closure$0                   (115 kB jump)
0x00000052374f5030 FnOnce::call_once
0x00000052374f5090 command_queue::impl$4::apply_or_drop_queued::closure$0
0x00000052374f50d0 unwind_safe::impl$25::call_once
0x00000052374f5130 catch_unwind::do_call
<unknown>
0x00000052374f51f0 std::panicking::catch_unwind
0x00000052374f51f0 std::panic::catch_unwind
0x00000052374f5290 RawCommandQueue::apply_or_drop_queued
...

Take the 115 kB frame in command_queue::impl$4::push::closure$0. That's the CommandMeta { consume_command_and_get_size } closure in command_queue.rs:162. I don't know if there's anything in there that could be changed to use less stack.

The next ones are in command_handling.rs:45, command_handling.rs:128, and commands/mod.rs:386. Not sure what that 38 kB used each time is.

Update

The Command, and the spawned impl Bundle, are 38 kB as serialised data in the command queue. So I'm guessing several of these functions end up storing it on the stack, and the big ones store it multiple times. Maybe in some cases we can explicitly avoid that.

[viridia]

@alice-i-cecile @cart I noticed that @ickshonpe mentioned running into a similar problem running the feathers example (it's mentioned in the focus rings PR).

As I'm not a windows user, I can't reproduce this myself. However, from the description given above, it sounds like it's not a problem specific to feathers but rather a consequence of the new spawning API using lots of stack when spawning a complex nested hierarchy.

I'd hate to ship the milestone with this bug: it doesn't look good if users want to try out the shiny new example and it immediately crashes. I can, of course, cut down on the size of the demo, but we should probably investigate the root cause a bit first.

[ejrh]

Changed the title to reflect that it's not specific to feathers.

Windows's small stack combined with dev-mode optimisation levels has exposed the problem but it's a lurking issue for other environments, once peoples' Bundles get big enough.

Most of the time Bundles will be small enough that it doesn't matter, and I guess there may be an unwanted performance cost to always allocating the Bundle to spawn. If the children! macro put its results into a Box or Vec that would alleviate the problem (and fixes the feathers example) but there's always the possibility someone wants to spawn enough big components in one entity that it still crashes.

Don't know how explicit we want the spawn API to be -- should there be separate functions/macros for keeping parts off the stack?

[viridia]

Most of the time Bundles will be small enough that it doesn't matter

While that may be true most of the time, it's not at all uncommon in UI work to spawn panels that have complex nested hierarchies. Particularly in editors. The feathers demo isn't particularly excessive compared to some UIs I have seen.