Opt-level profile override causes function miscompile to ud2 on MacOS

[mvlabat]

Opt-level profile override causes function miscompile to ud2 on MacOS. I wasn't able to reproduce this bug on Windows 10.

rustc version: 1.38.0-nightly (6e0d27d 2019-08-03)

The most minimal example I could come up with:
https://github.com/mvlabat/ud2

src/main.rs: https://github.com/mvlabat/ud2/blob/master/src/main.rs
Cargo.toml: https://github.com/mvlabat/ud2/blob/master/Cargo.toml
Note that I use profile-overrides nightly feature, and specify opt-level = 3 for the dependencies. (Also tested with level 2, it works the same way.)

Compiling and running this example in debug mode yields the following result:

mvlabat@Vladislav’s MacBook Pro ~/ud2 $ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.17s
     Running `target/debug/ud2`
Illegal instruction: 4

(lldb) run:

Process 20978 launched: '/Users/mvlabat/ud2/target/debug/ud2' (x86_64)
Process 20978 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x0000000100007574 ud2`specs::common::Errors::new::hd5e0e37501dd2b6f + 4 [opt]
ud2`specs::common::Errors::new::hd5e0e37501dd2b6f:
->  0x100007574 <+4>: ud2
    0x100007576 <+6>: nopw   %cs:(%rax,%rax)

ud2`_$LT$specs..common..Errors$u20$as$u20$core..fmt..Debug$GT$::fmt::h441fdac8397986f4:
    0x100007580 <+0>: pushq  %rbp
    0x100007581 <+1>: movq   %rsp, %rbp
Target 0: (ud2) stopped.

(lldb) thread backtrace all:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x0000000100007574 ud2`specs::common::Errors::new::hd5e0e37501dd2b6f + 4 [opt]
    frame #1: 0x0000000100000fb9 ud2`ud2::main::h6b15d9f5b8df8e75 at main.rs:4:12
    frame #2: 0x00000001000038b2 ud2`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h6c7b736215d1b105 at rt.rs:64:33
    frame #3: 0x0000000100011748 ud2`std::panicking::try::do_call::h49cc3cf4a82903ce [inlined] std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::he16126d1336d2248 at rt.rs:49:12 [opt]
    frame #4: 0x000000010001173c ud2`std::panicking::try::do_call::h49cc3cf4a82903ce at panicking.rs:296 [opt]
    frame #5: 0x0000000100012f9f ud2`__rust_maybe_catch_panic at lib.rs:80:7 [opt]
    frame #6: 0x00000001000120fe ud2`std::rt::lang_start_internal::h25b1b1c7c9699806 [inlined] std::panicking::try::hfe8d7d9e6cfd2e30 at panicking.rs:275:12 [opt]
    frame #7: 0x00000001000120cb ud2`std::rt::lang_start_internal::h25b1b1c7c9699806 [inlined] std::panic::catch_unwind::ha52b1f12c5d864f6 at panic.rs:394 [opt]
    frame #8: 0x00000001000120cb ud2`std::rt::lang_start_internal::h25b1b1c7c9699806 at rt.rs:48 [opt]
    frame #9: 0x0000000100003892 ud2`std::rt::lang_start::h2106b4e0263a89a6(main=(ud2`ud2::main::h6b15d9f5b8df8e75 at main.rs:3), argc=1, argv=0x00007ffeefbff680) at rt.rs:64:4
    frame #10: 0x00000001000010b2 ud2`main + 34
    frame #11: 0x00007fff774d03d5 libdyld.dylib`start + 1

(lldb) disas:

ud2`specs::common::Errors::new::hd5e0e37501dd2b6f:
    0x100007570 <+0>: pushq  %rbp
    0x100007571 <+1>: movq   %rsp, %rbp
->  0x100007574 <+4>: ud2
    0x100007576 <+6>: nopw   %cs:(%rax,%rax)

[Centril]

The most minimal example I could come up with:
https://github.com/mvlabat/ud2

---

Can you make a reproducer without using any dependencies?

[mvlabat]

@Centril I'm not so sure... Not every function gets optimized away, I only got that in my pet project with this particular dependency. I'll try that, though I can't promise I'll be able to get a reproducer without external dependencies.

[sfackler]

The example is using an old version of specs, which is using an old version of crossbeam, which has this suspicious line creating an uninitialized T (in this case a Box<dyn Error>): https://docs.rs/crossbeam/0.4.1/src/crossbeam/ms_queue.rs.html#71.

[mvlabat]

@Centril I tried to reproduce the bug with a workspace dependency (without using of external ones), but I've got no luck so far. Can't really identify the code which causes the miscompilation

[saethlin]

I do not think this is a miscompilation, just dubious code dating back from when we really didn't know much about UB in Rust that results from the rest of the language design.

The code in question executes UB, or tries to. Box has a niche: it may never be null and the compiler is allowed to assume that. But this code tries to create an uninitialized Box, which may have any bit pattern, including null. LLVM is permitted to and makes an attempt to assume the most-UB bit pattern in such cases.

Since #66059, this code just panics:

     Running `target/debug/ud2`
thread 'main' panicked at 'attempted to leave type `core::mem::manually_drop::ManuallyDrop<error::BoxedErr>` uninitialized, which is invalid', /home/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam-0.4.1/src/ms_queue.rs:71:45
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'attempted to leave type `internal::Local` uninitialized, which is invalid', /home/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam-epoch-0.5.2/src/internal.rs:482:59

cc @alice-i-cecile

[alice-i-cecile]

Great, I'm going to close this out now then.