Rust app crashes with segmentation fault

[kuzemchik]

Code compiled with Rust 1.70.0, 1.72.1, 1.73.0 yields code that is failing with segmentation fault in runtime.

I tried this code:

use std::convert::TryInto;
fn main() {
	let data:[f32; 1000*1000] = vec![1.0; 1000*1000]
        .try_into()
        .expect("Wrong matrix size!");
    print!("Result {}\n",data[0])	
}

I expected to see this happen:

• "Result 1"
• "Wrong matrix size!"
• Compilation Error
• Stack overflow

Instead, this happened:

• segmentation fault (signal: 11, SIGSEGV: invalid memory reference)

Code below works (just dropping the size of vec/array)

use std::convert::TryInto;
fn main() {
	let data:[f32; 100*100] = vec![1.0; 100*100]
        .try_into()
        .expect("Wrong matrix size!");
    print!("Result {}\n",data[0])	
}

Meta

rustc --version --verbose:

rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: aarch64-apple-darwin
release: 1.70.0
LLVM version: 16.0.2

rustc 1.72.1 (d5c2e9c34 2023-09-13)
binary: rustc
commit-hash: d5c2e9c342b358556da91d61ed4133f6f50fc0c3
commit-date: 2023-09-13
host: aarch64-apple-darwin
release: 1.72.1
LLVM version: 16.0.5

rustc 1.73.0 (cc66ad468 2023-10-03)
binary: rustc
commit-hash: cc66ad468955717ab92600c770da8c1601a4ff33
commit-date: 2023-10-03
host: aarch64-apple-darwin
release: 1.73.0
LLVM version: 17.0.2

Backtrace

➜  bug_report RUST_BACKTRACE=1 cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
➜  bug_report RUST_BACKTRACE=1 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/bug_report`
[1]    39304 segmentation fault  RUST_BACKTRACE=1 cargo run

[clubby789]

This is a stack overflow as you're constructing two very large literal on the stack, one that's copied into the vec and one that is copied out. In release mode this is optimised out. Ideally you should see the message

thread 'main' has overflowed its stack
fatal runtime error: stack overflow

rather than a segmention fault

[kuzemchik]

@clubby789 makes sense, thanks.
And I would assume that there is no expectation that stack overflow should trigger panic.
Should I close the issue then?

[saethlin]

A stack overflow, especially one written like this, is supposed to hit a stack protector. From the description, it sounds like that is not happening. On Linux, I see this:

    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/scratch`

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Aborted (core dumped)

It's not clear to me if what you are observing is a bug in the stack protectors on aarch64-apple-darwin.

[bjorn3]

We don't enable stack probes on AArch64.

[iximeow]

this looks like a dupe of #107814 and presumably is also fixed.

[saethlin]

Sounds good to me!