do not seg fault on stack overflow

[umutacar]

It seems that rust knows when stack overflows
#109533 (comment)

If so, then it would be better for it to report the stack overflow, instead of seg faulting.

[csmoe]

fn main() {
let a:[i32;10_000_000] = [10;10_000_000];
}
rustc has the report already.

[jyn514]

What do you mean by "report"? It only has this knowledge at runtime, and it does report it at runtime:

fatal runtime error: stack overflow

[umutacar]

I receive this segmentation fault:

[tgross35]

@umutacar could you post a minimal reproduction of the code you are using? Also rust version and such

it looks like you have a literal segfault and not a stack overflow

[pnkfelix]

What target you are on is especially relevant.

[umutacar]

I am compiling on an Apple computer targeting the Mac I chipset.
The code is this:

fn main() {
    let a:[i32;10_000_000] = [10;10_000_000];
}

here is cargo.toml

[package]
name = "stackarray"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

[chebbyChefNEQ]

Hi, my understanding has been that this is due to lack of stack probing support in LLVM on aarch64. But after LLVM 18 upgrade this should have been fixed.

However, I'm still able to repro on cargo 1.77.1 on Mac

(base) ➜  cargo run
   Compiling rs v0.1.0 (/Users/robmeng/workspace/1brc)
    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/rs`
[1]    60568 segmentation fault  cargo run
(base) ➜  ✗ cat src/main.rs
fn main() {
    let _buf = [0; 1024 * 1024 * 10];
}
(base) ➜ ✗ cargo --version
cargo 1.77.1 (e52e36006 2024-03-26)

[tgross35]

Hi, my understanding has been that this is due to lack of stack probing support in LLVM on aarch64. But after LLVM 18 upgrade this should have been fixed.

Horray! Then there is a fix!

$ cat fail.rs
fn main() {
    let _buf = [0; 1024 * 1024 * 10];
}
$ rustc +stable fail.rs
$ ./fail
zsh: segmentation fault  ./fail
$ rustc +nightly fail.rs
$ ./fail

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
zsh: abort      ./fail

However, I'm still able to repro on cargo 1.77.1 on Mac

LLVM18 is coming with 1.78, not 1.77 :) #120055

I think this should be good to close then, unless @umutacar or @chebbyChefNEQ you have further issues testing with the latest nightly.

[chebbyChefNEQ]

ah! somehow I thought stable is already on 18 haha. should have checked by rustc. yep nightly is fixed

[tgross35]

If anyone is interested it could be good to add the example as a run-fail test to make sure it panics rather than segfaults, which would be pretty easy. (not positive if we can make this guarantee on all platforms)

[Enselic]

Triage: Looks like there already is a test with tests/ui/runtime/out-of-stack.rs. So let's go ahead and close this as fixed now.