Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

do not seg fault on stack overflow #109541

Open
umutacar opened this issue Mar 23, 2023 · 10 comments
Open

do not seg fault on stack overflow #109541

umutacar opened this issue Mar 23, 2023 · 10 comments
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@umutacar
Copy link

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
Copy link
Member

csmoe commented Mar 24, 2023

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

rustc has the report already.

@jyn514
Copy link
Member

jyn514 commented Mar 25, 2023

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

@jyn514 jyn514 added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Mar 25, 2023
@umutacar
Copy link
Author

I receive this segmentation fault:
image

@tgross35
Copy link
Contributor

tgross35 commented Mar 29, 2023

@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
Copy link
Member

What target you are on is especially relevant.

@umutacar
Copy link
Author

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]

@Noratrieb Noratrieb added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 5, 2023
@chebbyChefNEQ
Copy link

chebbyChefNEQ commented Apr 11, 2024

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
Copy link
Contributor

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
Copy link

chebbyChefNEQ commented Apr 12, 2024

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

@tgross35
Copy link
Contributor

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants