panic in program that shouldn't panic when compiling at optimization level 1 or 2

[mrwright]

It looks like if a function called from main contains just a loop {}, and it's compiled at optimization level 1 or 2, the program will panic when run instead of looping as it's supposed to.

Contents of main.rs:

fn x() { loop {} }

fn main() { x(); }

I expect this to loop forever when run. Instead, when compiled with rustc -C opt-level=1 main.rs and run, it panics; with RUST_BACKTRACE=1 set, the output is

thread 'main' panicked at 'assertion failed: c.borrow().is_none()', ../src/libstd/sys/common/thread_info.rs:51
stack backtrace:
   1:     0x56456e2de7ff - std::sys::backtrace::tracing::imp::write::h6f1d53a70916b90d
   2:     0x56456e2e12ad - std::panicking::default_hook::{{closure}}::h137e876f7d3b5850
   3:     0x56456e2e080a - std::panicking::default_hook::h0ac3811ec7cee78c
   4:     0x56456e2e0d58 - std::panicking::rust_panic_with_hook::hc303199e04562edf
   5:     0x56456e2e0b9f - std::panicking::begin_panic::h341b039f84d0b176
   6:     0x56456e2de3ef - std::sys_common::thread_info::set::h6f96b62c207d3b7d
   7:     0x56456e2dfdd9 - std::rt::lang_start::h538f8960e7644c80
   8:     0x56456e2e8d76 - __rust_maybe_catch_panic
   9:     0x56456e2e0081 - std::rt::lang_start::h538f8960e7644c80
  10:     0x7fb381dce2b0 - __libc_start_main
  11:     0x56456e2da349 - _start
  12:                0x0 - <unknown>

Tested on rustc 1.13.0 (2c6933acc 2016-11-07), rustc 1.13.0-beta.3 (106d18793 2016-11-04), and rustc 1.14.0-nightly (cae6ab1c4 2016-11-05); the issue occurs on all three.

It also (unsurprisingly) happens with opt-level=2. It does not occur at optimization level 0, and doesn't occur if the loop is in main itself rather than a function that main calls.

Output of rustc --version --verbose for the stable rustc:

rustc 1.13.0 (2c6933acc 2016-11-07)               
binary: rustc
commit-hash: 2c6933acc05c61e041be764cb1331f6281993f3f
commit-date: 2016-11-07
host: x86_64-unknown-linux-gnu
release: 1.13.0

[TimNN]

This is a regression from 1.11.0 to 1.12.0.

Also, on OS X this segfaults... (wenn compiled with opt-level > 0)

Backtrace on OS X / nightly:

(lldb) bt
* thread #1: tid = 0x5487c7, 0x000000010000700c lfail`std::sys::imp::stack_overflow::imp::make_handler [inlined] core::mem::zeroed<libc::unix::bsd::apple::stack_t> + 8 at mem.rs:334, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x000000010000700c lfail`std::sys::imp::stack_overflow::imp::make_handler [inlined] core::mem::zeroed<libc::unix::bsd::apple::stack_t> + 8 at mem.rs:334 [opt]
    frame #1: 0x0000000100007004 lfail`std::sys::imp::stack_overflow::imp::make_handler + 4 at stack_overflow.rs:173 [opt]
    frame #2: 0x0000000100007bf3 lfail`std::rt::lang_start [inlined] std::sys::imp::stack_overflow::imp::init + 82 at stack_overflow.rs:134 [opt]
    frame #3: 0x0000000100007ba1 lfail`std::rt::lang_start + 177 at rt.rs:44 [opt]

[TimNN]

Introduced between nightly-2016-08-01 and nightly-2016-08-02 (Changes).

That range includes (as one might have expected) the llvm upgrade to 3.9 (#34743).

[TimNN]

I can reproduce this with clang (on OS X, homebrew version clang version 3.9.0):

void x(void) {
    while(1) {}
}

void main(void) {
    x();
}

Fails with a "bus error", backtrace:

* thread #1: tid = 0x54f6ef, 0x0000000100000fb4 lcfail, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x100000fb0)
    frame #0: 0x0000000100000fb4 lcfail
->  0x100000fb4: addl   %eax, (%rax)
    0x100000fb6: addb   %al, (%rax)
    0x100000fb8: sbbb   $0x0, %al
    0x100000fba: addb   %al, (%rax)
(lldb) bt
* thread #1: tid = 0x54f6ef, 0x0000000100000fb4 lcfail, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x100000fb0)
  * frame #0: 0x0000000100000fb4 lcfail
    frame #1: 0x00007fff90d4b5ad libdyld.dylib`start + 1
    frame #2: 0x00007fff90d4b5ad libdyld.dylib`start + 1

[TimNN]

So this is apparently https://llvm.org/bugs/show_bug.cgi?id=965 (the duplicates are basically exactly the c repro I came up with).

However that bug has been reported in 2006, so I wonder why this doesn't trigger before 1.12.0.

[TimNN]

This is likely related to #18785, although that one uses infinite recursion instead of an infinite loop.

[nagisa]

First of all, this is a duplicate of #28728.

LLVM simply does not consider infinite looping a case of side-effect (which is at odds with what Rust considers them to be) and is a well known mismatch between LLVM and Rust semantics.

As to why it is a “regression”… obviously because something changed in how we generate code (cough, MIR, cough) in a way that makes LLVM able to apply some of its transformations, where it wasn’t been able before. Then again, its not an issue that didn’t exist before, only something that is now exposed in more cases.

[arielb1]

@nagisa

The regression seems to be caused by updating LLVM to 3.9, rather than by a change on our side (after all, there are only so many ways to . I think this can safely be closed as a duplicate.