Stack space used by assertions ever-growing with opt-level=0, causing stack overflow

[Bromeon]

When using bindgen, I ran into the issue that the generated tests -- which can contain a lot of assert_eq! statements in one function -- seem to linearly allocate stack space, not reusing space from a previous independent assertion. With a sufficient number of statements, this causes a stack overflow.

The problem does not occur with RUSTFLAGS=-C opt-level=2.

I made a reproducible example in this Gist. Couldn't paste it here in a <details> block due to character limit.

Downstream issue: rust-lang/rust-bindgen#2218.
Found a similar issue #34283, but it's probably not directly related.

I'm not sure if the current behavior is by design (possibly excessive stack usage as a result of no optimizations), but it is a problem for many code-generation scenarios.

Meta

rustc --version --verbose:

rustc 1.61.0 (fe5b13d68 2022-05-18)
binary: rustc
commit-hash: fe5b13d681f25ee6474be29d748c65adcd91f69e
commit-date: 2022-05-18
host: x86_64-pc-windows-msvc
release: 1.61.0
LLVM version: 14.0.0

Backtrace

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

Process finished with exit code -1073741571 (0xC00000FD)

[ChrisDenton]

A workaround on Windows is to increase the maximum stack size. For example, in a .cargo/config.toml configuration file (where 0x800000 is the size in bytes):

[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "link-arg=/STACK:0x800000"]

You could also set the link-arg in a build script.

[Bromeon]

A workaround on Windows is to increase the maximum stack size.

I'm not sure this is a good workaround, as it will simply delay the issue and make it harder to notice. It's also harder to do portably and reliably. This stack overflow is not typically triggered in manually written code, but rather generated one, which can -- depending on the application -- be very long.

A better workaround, that bindgen now uses, is to declare local functions and immediately call them. Stack space is released at the end of a function call. Local blocks { } unfortunately don't seem to work.

[Enselic]

Triage: Thank you for reporting. Adding optimizations to opt-level 0 would defeat the purpose of opt-level 0; fast and "straightforward" compilation. To me it does not seem unreasonable to require manually increasing the stack size with opt-level 0 for the giant example code you posted. I'll close this as won't fix, but of course feel free to reopen if you strongly disagree.

[Bromeon]

Thank you for your answer!

As stated 2 years ago, I'm not sure if increasing the stack size is a suitable workaround -- the problem just manifests itself more rarely and can cause even more debugging if tested in a slightly different configuration.

Furthermore, is preventing a stack overflow during compilation really an optimization? The fact that higher opt levels avoid the overflow seems to be more a side effect than by-design. But I see of course the goal to keep generated code simple.

If there is wide agreement among Rust maintainers that this isn't worth fixing, do you think it deserves a dedicated error message (not sure if imminent stack overflow is detectable at all, or if there's some context available after-the-fact). Or alternatively, some documentation about compiler limits and such behavior?

(Note that I cannot reopen the issue myself, but it's probably OK given how rarely this occurs in practice. Would still be nice to hear more input on the error message/docs. Thanks!)

[Enselic]

In this case a good workaround seems to have been found already in rust-lang/rust-bindgen#2218 ?

Furthermore, is preventing a stack overflow during compilation really an optimization?

If it was not an optimization we would not have the problem in opt-level 0 I think?

not sure if imminent stack overflow is detectable at all, or if there's some context available after-the-fact

(safe) Rust guarantees no undefined behavior, which includes detecting stack overflow. Often it can be reported with a nice error, but not always. See https://users.rust-lang.org/t/is-rust-guaranteed-to-detect-stack-overflows/52593 for some more discussion regarding this.

Note that I cannot reopen the issue myself

Oh, thanks for letting me know. That's weird. Since you can file new issues it seems logical to allow you to re-open your own issues. Anyway, then let's keep discussing until we agree on what to do with this issue.