STATUS_ACCESS_VIOLATION on 'index out of bounds' Windows 7 with lto and avx

[jamesjerram]

With avx and lto enabled, index out of bounds causes a STATUS_ACCESS_VIOLATION instead of a panic. Initially encountered this problem in a program using rand::thread_rng() but narrowed down to a simpler test case found in issue #51794.

I tried this code:

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

with flags -C lto -C target-feature=+avx

I expected to see this happen:

PS > cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target\debug\rand_test.exe`
thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', src\main.rs:5:20
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: process didn't exit successfully: `target\debug\rand_test.exe` (exit code: 101)

Instead, this happened:

PS > cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target\debug\rand_test.exe`
error: process didn't exit successfully: `target\debug\rand_test.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

Meta

rustc 1.36.0 (a53f9df 2019-07-03)
binary: rustc
commit-hash: a53f9df
commit-date: 2019-07-03
host: x86_64-pc-windows-msvc
release: 1.36.0
LLVM version: 8.0

lldb output:

(lldb) target create "target\\debug\\rand_test.exe"
Current executable set to 'target\debug\rand_test.exe' (x86_64).
(lldb) run
Process 6676 launched: 'target\debug\rand_test.exe' (x86_64)
Process 6676 stopped
* thread #1, stop reason = Exception 0xc0000005 encountered at address 0x13f0d6175
    frame #0: 0x000000013f0d6175 rand_test.exe
->  0x13f0d6175: vmovaps 0x60(%rcx), %ymm0
    0x13f0d617d: movl   $0x1, %edx
    0x13f0d6182: vmovq  %rdx, %xmm1
    0x13f0d6187: vmovaps %xmm1, %xmm2

[nikic]

Can you produce a backtrace for the crash? I'm assuming it happens somewhere in the panic implementation?

[jamesjerram]

The program stops before it can print a backtrace, and I don't think it's panic-related because upon further testing, the same access violation occurs even with i = 0 , which should be valid and produces no error or panic when run without the flags.

That being said, here's the backtrace for i = 1 without the flags set:

stack backtrace:
   0: std::sys_common::backtrace::_print
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\/src\libstd\sys_common\backtrace.rs:71
   1: std::panicking::default_hook::{{closure}}
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\/src\libstd\panicking.rs:197
   2: std::panicking::default_hook
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\/src\libstd\panicking.rs:211
   3: std::panicking::rust_panic_with_hook
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\/src\libstd\panicking.rs:474
   4: std::panicking::continue_panic_fmt
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\/src\libstd\panicking.rs:381
   5: std::panicking::rust_begin_panic
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\/src\libstd\panicking.rs:308
   6: core::panicking::panic_fmt
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\/src\libcore\panicking.rs:85
   7: core::panicking::panic_bounds_check
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\/src\libcore\panicking.rs:61
   8: rand_test::main
             at .\src\main.rs:5
   9: std::rt::lang_start::{{closure}}<()>
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\src\libstd\rt.rs:64
  10: std::panicking::try::do_call<closure,i32>
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\/src\libstd\panicking.rs:293
  11: panic_unwind::__rust_maybe_catch_panic
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\/src\libpanic_unwind\lib.rs:85
  12: std::rt::lang_start_internal
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\/src\libstd\rt.rs:48
  13: std::rt::lang_start<()>
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\src\libstd\rt.rs:64
  14: main
  15: __scrt_common_main_seh
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  16: BaseThreadInitThunk
  17: RtlUserThreadStart

and the debugger output for i=0 with the flags set:

* thread #1, stop reason = Exception 0xc0000005 encountered at address 0x13fdfcf87
    frame #0: 0x000000013fdfcf87 rand_test.exe
->  0x13fdfcf87: vmovaps 0xa0(%rcx), %ymm0
    0x13fdfcf8f: movl   $0x1, %edx
    0x13fdfcf94: vmovq  %rdx, %xmm1
    0x13fdfcf99: vmovaps %xmm1, %xmm2

[nikic]

Sorry, what I had in mind here is a backtrace from lldb (typing in backtrace into the lldb command line should produce it).

[jamesjerram]

(lldb) bt
* thread #1, stop reason = Exception 0xc0000005 encountered at address 0x13f09cf87
  * frame #0: 0x000000013f09cf87 rand_test.exe
    frame #1: 0x000000000021f830

[retep998]

Are you certain that your CPU is capable of executing AVX instructions?

[jamesjerram]

It's an i5-4590, and is able to run the intrinsics in std::arch directly without issue. The problem also crops up when compiling with target-cpu=native. These are all the features detected by is_x86_feature_detected!: aes, pclmulqdq, rdrand, tsc, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, avx, avx2, fma, bmi1, bmi2, abm, lzcnt, popcnt, fxsr, xsave, xsaveopt

[mati865]

Windows GNU nightly-2019-07-18 (built with rustc -C lto -C target-feature=+avx -O test.rs):

# i = 1
$ ./test.exe
thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', test.rs:4:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

# i = 0
$ ./test.exe
1

@jamesjerram can you check if it works with nightly?

[nagisa]

Assigning to myself to see if I can reproduce it myself and @nikic as they are somewhat actively on top of LLVM issues.

[jamesjerram]

I can confirm that it works properly with nightly.

[nikic]

Probably a fix was pulled in with the LLVM update. As we can't backport that, this issue can probably be closed?