ACCESS_VIOLATION when dereferencing once_cell::Lazy in closure with LTO

[roblabla]

The code in the following repository crashes with an ACCESS_VIOLATION on Windows: https://github.com/roblabla/reproduce-boom/

To reproduce, four things are needed:

• Using LLD linker
• Building with Thin LTO
• Splitting the main binary and a library.

EDIT: Better reproducer can be found here.

The main.rs file:

fn main() {
    reproducer::run()();
}

The lib.rs file:

use once_cell::sync::Lazy;

static CHANNEL: Lazy<()> = Lazy::new(|| ());

pub fn run() -> impl FnOnce() {
    || {
        let _ = *CHANNEL;
        println!("Did not crash.")
    }
}

Running cargo run --release will trigger the following output:

   Finished release [optimized + debuginfo] target(s) in 0.02s
     Running `C:/Users/roblabla/cargo_target\release\reproducer.exe`
error: process didn't exit successfully: `C:/Users/roblabla/cargo_target\release\reproducer.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

---

This issue seems related to ThinLTO. It only occurs on windows.

Meta

rustc --version --verbose:

rustc 1.49.0 (e1884a8e3 2020-12-29)
binary: rustc
commit-hash: e1884a8e3c3e813aada8254edfa120e85bf5ffca
commit-date: 2020-12-29
host: x86_64-pc-windows-msvc
release: 1.49.0

Backtrace

[0x0]   reproducer!core::sync::atomic::atomic_compare_exchange + 0x3
[0x1]   reproducer!core::sync::atomic::AtomicUsize::compare_exchange + 0x3
[0x2]   reproducer!core::sync::atomic::AtomicUsize::compare_and_swap + 0x3
[0x3]   reproducer!once_cell::imp::wait + 0x5c
[0x4]   reproducer!once_cell::imp::initialize_inner + 0xcc
[0x5]   reproducer!once_cell::imp::OnceCell<tuple<>>::initialize<tuple<>,closure-0,once_cell::sync::{{impl}}::get_or_init::Void> + 0x41
[0x6]   reproducer!once_cell::sync::OnceCell<tuple<>>::get_or_try_init + 0x19
[0x7]   reproducer!once_cell::sync::OnceCell<tuple<>>::get_or_init + 0x19
[0x8]   reproducer!once_cell::sync::Lazy<tuple<>, fn()>::force + 0x19
[0x9]   reproducer!once_cell::sync::{{impl}}::deref + 0x19
[0xa]   reproducer!reproducer::run::{{closure}} + 0x19
[0xb]   reproducer!core::future::from_generator::{{impl}}::poll + 0x19
[0xc]   reproducer!reproducer::run + 0x7d
[0xd]   reproducer!reproducer::main + 0xc6
[0xe]   reproducer!core::ops::function::FnOnce::call_once + 0x2
[0xf]   reproducer!std::sys_common::backtrace::__rust_begin_short_backtrace<fn(),tuple<>> + 0x6
[0x10]   reproducer!std::rt::lang_start::{{closure}}<tuple<>> + 0xc
[0x11]   reproducer!core::ops::function::impls::{{impl}}::call_once + 0x6
[0x12]   reproducer!std::panicking::try::do_call + 0x6
[0x13]   reproducer!std::panicking::try + 0x6
[0x14]   reproducer!std::panic::catch_unwind + 0x6
[0x15]   reproducer!std::rt::lang_start_internal + 0xd9
[0x16]   reproducer!main + 0x27
[0x17]   reproducer!invoke_main + 0x22
[0x18]   reproducer!__scrt_common_main_seh + 0x10c
[0x19]   KERNEL32!BaseThreadInitThunk + 0x14
[0x1a]   ntdll!RtlUserThreadStart + 0x21

[CryZe]

The reproducer::CHANNEL symbol gets mislinked. Here's where the symbol's address gets loaded into the register:

If you check what's at that address, you find it's the beginning of the binary that is loaded as read only into the RAM:

which later segfaults as that is interpreted as the Lazy's internal AtomicUsize, at which point everything goes wrong:

The +crt-static is not necessary btw. It's a problem involving the fact that there's multiple crates, rust-lld and thin-lto.

[apiraino]

@rustbot ping windows

[rustbot]

Hey Windows Group! This bug has been identified as a good "Windows candidate".
In case it's useful, here are some instructions for tackling these sorts of
bugs. Maybe take a look?
Thanks! <3

cc @arlosi @danielframpton @gdr-at-ms @kennykerr @luqmana @lzybkr @nico-abram @retep998 @rylev @sivadeilra