calling functions casue STATUS_STACK_OVERFL on Windows

[psionic12]

I can't provide a minum reproducable code, but it can be reproduce by running the example in project https://github.com/derivator/egui_vulkano, just git clone it, and run cargo run --example example, the program will crash with message:

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

What the crate does is not important (it's for some graphic thing), the crash happens when calling the function let pipeline = create_pipeline(device.clone(), subpass.clone())?; in lib.rs: 120, the CPU never run into the function create_pipeline, but cause the stack overflow problem.

I don't have a macOS or Linux by hand, I'll test this on macOS tomorrow.

Here's the information of my machin: Window: 10 Rustc: rustc 1.57.0 (f1edd0429 2021-11-29) MSVC: 15.9.37 CPU: AMD 5900X

[hkratz]

@psionic12 Why do you think that this is an issue with Rust and not one with egui_vulkano or a dependent crate?

[psionic12]

@hkratz because I set break points and investigate for a while, the stack looks weird to me, there's no FFI, no recursion, just calling a function, but the stack overflowed without the body of function even get run. I also add logs, the log illustrate that too.

I'm not 100% percent sure this is a bug of rustc, but it is really unusual, maybe it is worth investigating.

Furthermore, I'll upload assembly codes by using dumpobj when I have time, it may help

[daigennki]

Likely related issue: https://github.com/vulkano-rs/vulkano/issues/1790

This reply might be of particular interest here:

After some messing around I was able to replicate this with ulimit -s 1024000 on Linux. I noticed that the parse function mentioned in the error above is trying to use 1034552 bytes of stack space, which just barely goes over that limit.

However, when I compile the example in release mode, the same function only uses 488 bytes of stack space. So this seems to be a matter of the Rust compiler producing terrible code without optimisations, and Windows having a smaller stack size than Linux.

[ChrisDenton]

Until this is improved, one workaround might be to try increasing the stack size using link-arg. E.g. for MSVC toolchains try /stack:8388608. For gnu try -Wl,--stack,8388608. This gives an 8 MiB stack, similar to a typical Linux stack size.

Example .cargo\config.toml:

[target.'cfg(all(windows, target_env="msvc"))']
rustflags = [
    "-C", "link-arg=/stack:8388608"
]

Edit you can also use a build script if using a newer version of Cargo, which might be better:

// build.rs
use std::env::var;

fn main() {
    // 8 MiB stack size
    let stack_size = 8 * 1024 * 1024;
    if var("CARGO_CFG_WINDOWS").is_ok() && var("CARGO_CFG_TARGET_ENV").as_deref() == Ok("msvc") {
        // sets the stack size for bins:
        println!("cargo:rustc-link-arg-bins=/stack:{}", stack_size);
    }
}

[Enselic]

So this seems to be a matter of the Rust compiler producing terrible code without optimisations

Triage: Maybe the Rust compiler is at fault here. To conclude yes or no, we're going to need a minimal reproducer.

[Enselic]

First I should ask: Can this still be reproduced? If not, I propose we close this issue as obsolete.