segfault on 'index out of bounds' OS X Yosemite

[felipenoris]

I get Segmentation Fault on this code when running the debug binary.

Only happens on OS X Yosemite 10.10.5 .

fn main() {
    let x = [1];
    println!("{}", x[1]);
}

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/segfault`
Segmentation fault: 11

$ cargo run --release
    Finished release [optimized] target(s) in 0.02s
     Running `target/release/segfault`
thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', src/main.rs:3:20
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Meta

rustc 1.27.0 (3eda71b 2018-06-19)
binary: rustc
commit-hash: 3eda71b
commit-date: 2018-06-19
host: x86_64-apple-darwin
release: 1.27.0
LLVM version: 6.0

[Mark-Simulacrum]

I cannot reproduce on macOS 10.13.5 (High Sierra).

@rust-lang/release if anyone can reproduce and bisect, that would be amazing.

cc @rust-lang/compiler -- stable regression

[kennytm]

I bet it is the same cause as #51758 (misaligned TLS).

[Mark-Simulacrum]

Seems likely -- this is in stable, though, so probably not caused by that. Getting confirmation would be good as well.

[kennytm]

The use of --release matches #50586

[Mark-Simulacrum]

The use of --release matches #50586

This is the reverse of that PR; this bug seems to only happen without --release whereas that one happens only with it.

[nikomatsakis]

This does indeed seem quite bad.

[nikomatsakis]

I cannot reproduce on my laptop, but it is 10.11.6. I'll have to see if I have a machine running 10.10 anywhere.

[kennytm]

@felipenoris Could you load target/debug/segfault into a debugger (gdb or lldb) and get the backtrace when it segfault?

[felipenoris]

Sure. I'll work on that.

[felipenoris]

$ lldb segfault
(lldb) target create "segfault"
Current executable set to 'segfault' (x86_64).
(lldb) run
Process 57139 launched: '/Users/felipenoris/Documents/src/learnrust/segfault/target/debug/segfault' (x86_64)
segfault was compiled with optimization - stepping may behave oddly; variables may not be available.
Process 57139 stopped
* thread #1: tid = 0x793cbc, 0x0000000100011abf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 [inlined] core::ptr::swap_nonoverlapping_bytes::h90af7d9428701cbf + 16 at ptr.rs:237, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x0000000100011abf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 [inlined] core::ptr::swap_nonoverlapping_bytes::h90af7d9428701cbf + 16 at ptr.rs:237 [opt]

[oli-obk]

does running the bt command after the segfault produce anything useful?

[kennytm]

Thanks @felipenoris! The segfault again happens from mem::swap.

BTW could you also try this:

1. Install rustup-install-toolchain-master, either by

   • cargo install rustup-install-toolchain-master, or if it segfaults,
   • download the prebuilt binary from https://github.com/kennytm/rustup-toolchain-install-master/releases/tag/v1.1.0, unzip it, chmod a+x, then move the binary into ~/.cargo/bin or anywhere in $PATH

2. Install a new rustup toolchain from Do not allow LLVM to increase a TLS's alignment on macOS. #51828 with

   rustup-install-toolchain-master 77a8ed98fc66821a410b0c4696ba99b07b713467

3. Test using this toolchain:

   cargo +77a8ed98fc66821a410b0c4696ba99b07b713467 run

[felipenoris]

(lldb) bt
* thread #1: tid = 0x796f84, 0x0000000100011abf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 [inlined] core::ptr::swap_nonoverlapping_bytes::h90af7d9428701cbf + 16 at ptr.rs:237, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x0000000100011abf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 [inlined] core::ptr::swap_nonoverlapping_bytes::h90af7d9428701cbf + 16 at ptr.rs:237 [opt]
    frame #1: 0x0000000100011aaf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 [inlined] core::ptr::swap_nonoverlapping::h644cc6a65b724c83 at ptr.rs:187 [opt]
    frame #2: 0x0000000100011aaf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 [inlined] core::mem::swap::h5a9cd575e67a6181 at mem.rs:634 [opt]
    frame #3: 0x0000000100011aaf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 [inlined] core::mem::replace::hb91d071e3288f217 at mem.rs:691 [opt]
    frame #4: 0x0000000100011aaf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 [inlined] _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::init::hdc127b6594dc2f82 at local.rs:270 [opt]
    frame #5: 0x0000000100011aaf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 [inlined] _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::try_with::h35683f0829174f6d at local.rs:296 [opt]
    frame #6: 0x0000000100011aaf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 [inlined] _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::hd95e5656daaba459 at local.rs:248 [opt]
    frame #7: 0x0000000100011aaf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 [inlined] std::panicking::update_panic_count::h9566b85bd2bcf46e at panicking.rs:240 [opt]
    frame #8: 0x0000000100011aaf segfault`std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7 + 143 at panicking.rs:437 [opt]
    frame #9: 0x00000001000116b1 segfault`std::panicking::begin_panic_fmt::h2a4ecdf0c76cf1c3 + 49 at panicking.rs:350 [opt]
    frame #10: 0x0000000100011673 segfault`rust_begin_unwind + 35 at panicking.rs:328 [opt]
    frame #11: 0x00000001000463d6 segfault`core::panicking::panic_fmt::hb253bce78d883c0b + 118 at panicking.rs:71 [opt]
    frame #12: 0x0000000100046354 segfault`core::panicking::panic_bounds_check::h80816a3e0195fd50 + 116 at panicking.rs:58 [opt]
    frame #13: 0x0000000100000af7 segfault`segfault::main::hdaaaca17ad5afac1 + 199 at main.rs:3
    frame #14: 0x0000000100000ba2 segfault`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::hd2353479c4883d87 + 18 at rt.rs:74
    frame #15: 0x0000000100011638 segfault`std::panicking::try::do_call::h780530fa434ed2ed [inlined] std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::hcfde3e1c19e6fa13 + 24 at rt.rs:59 [opt]
    frame #16: 0x000000010001162c segfault`std::panicking::try::do_call::h780530fa434ed2ed + 12 at panicking.rs:310 [opt]
    frame #17: 0x000000010001d2bf segfault`__rust_maybe_catch_panic + 31 at lib.rs:105 [opt]
    frame #18: 0x0000000100009c82 segfault`std::rt::lang_start_internal::h46f9f692ece7505b [inlined] std::panicking::try::h0c5a2273ff0725da + 51 at panicking.rs:289 [opt]
    frame #19: 0x0000000100009c4f segfault`std::rt::lang_start_internal::h46f9f692ece7505b [inlined] std::panic::catch_unwind::h3474c6e3bb49278a at panic.rs:374 [opt]
    frame #20: 0x0000000100009c4f segfault`std::rt::lang_start_internal::h46f9f692ece7505b + 191 at rt.rs:58 [opt]
    frame #21: 0x0000000100000b82 segfault`std::rt::lang_start::hd3629e9310e6f506(main=(segfault`segfault::main::hdaaaca17ad5afac1 at main.rs:1), argc=1, argv=0x00007fff5fbffa38) + 66 at rt.rs:74
    frame #22: 0x0000000100000b25 segfault`main + 37
    frame #23: 0x00007fff894935c9 libdyld.dylib`start + 1
    frame #24: 0x00007fff894935c9 libdyld.dylib`start + 1

[felipenoris]

About the toolchain:

$ cargo install rustup-toolchain-install-master
...
$ rustup-toolchain-install-master 77a8ed98fc66821a410b0c4696ba99b07b713467
Segmentation fault: 11

[kennytm]

@felipenoris Does the prebuilt binary work then?

[felipenoris]

@kennytm , with the prebuilt binaries results looks good. It replaces the runtime error with compile-time error.

$ cargo +77a8ed98fc66821a410b0c4696ba99b07b713467 run
   Compiling segfault v0.1.0 (file:///Users/felipenoris/Documents/src/learnrust/segfault)
error: index out of bounds: the len is 1 but the index is 1
 --> src/main.rs:3:20
  |
3 |     println!("{}", x[1]);
  |                    ^^^^
  |
  = note: #[deny(const_err)] on by default

error: aborting due to previous error

error: Could not compile `segfault`.

To learn more, run the command again with --verbose.

[felipenoris]

Even if I rewrite the program to get a runtime error, the segfault doesn't happen.

fn main() {
    let x = [1];
    let i = 1; 
    println!("{}", x[i]);
}

$ cargo +77a8ed98fc66821a410b0c4696ba99b07b713467 run
   Compiling segfault v0.1.0 (file:///Users/felipenoris/Documents/src/learnrust/segfault)
    Finished dev [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/segfault`
thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', src/main.rs:4:20
note: Run with `RUST_BACKTRACE=1` for a backtrace.

[nikomatsakis]

Assigning to @kennytm, who seems to be making good progress here (cc #51828)

[nikomatsakis]

Some discussion on IRC here https://botbot.me/mozilla/rustc/2018-06-28/?msg=101569375&page=2

[felipenoris]

I got another code example that reproduces the segfault. Again, the solution by @kennytm also covers this.

fn main() {
    let i: u8 = 254;
    println!("{}", i+2);
}

$ cargo run
   Compiling strings v0.1.0 (file:///Users/felipenoris/Documents/src/learnrust/strings)
    Finished dev [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/strings`
Segmentation fault: 11
$ cargo +77a8ed98fc66821a410b0c4696ba99b07b713467 run
   Compiling strings v0.1.0 (file:///Users/felipenoris/Documents/src/learnrust/strings)
    Finished dev [unoptimized + debuginfo] target(s) in 1.57s
     Running `target/debug/strings`
thread 'main' panicked at 'attempt to add with overflow', src/main.rs:5:20
note: Run with `RUST_BACKTRACE=1` for a backtrace.