search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
98.81k stars 12.77k forks source link

STATUS_ACCESS_VIOLATION when running rend3 on Windows MSVC linked with LLD and thin LTO #111480

Open Elabajaba opened 1 year ago

Elabajaba commented 1 year ago

I'm getting a crash when running the rend3 examples in --release mode with lto=thin and using LLD. (edit: Happens in both dev builds and release builds when using thinLTO)

Rend3 repo: https://github.com/BVE-Reborn/rend3 Tested commit: 4d107951a3ba62a58a7be1849eb670d05f269e20

I expected to see this happen: It doesn't crash instantly when attempting to run it.

Instead, this happened: It crashes instantly when attempting to run the examples.

Meta

rustc --version --verbose:

rustc 1.69.0 (84c898d65 2023-04-16)
binary: rustc
commit-hash: 84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc
commit-date: 2023-04-16
host: x86_64-pc-windows-msvc
release: 1.69.0
LLVM version: 15.0.7

tested nightly:

rustc 1.71.0-nightly (cba14074b 2023-05-10)
binary: rustc
commit-hash: cba14074bb4cc12bfe918eabd0d52a3999b2a461
commit-date: 2023-05-10
host: x86_64-pc-windows-msvc
release: 1.71.0-nightly
LLVM version: 16.0.2

There's no backtrace, but running it in windbg it just loops these errors:

(54f0.fac): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
cube!core::sync::atomic::atomic_compare_exchange+0x3 [inlined in cube!once_cell::imp::initialize_or_wait+0xab]:
00007ff7`b833645b f0490fb15d00    lock cmpxchg qword ptr [r13],rbx ds:00007ff7`b81d0000=0000000100785a4d
(54f0.fac): Access violation - code c0000005 (!!! second chance !!!)
cube!core::sync::atomic::atomic_compare_exchange+0x3 [inlined in cube!once_cell::imp::initialize_or_wait+0xab]:
00007ff7`b833645b f0490fb15d00    lock cmpxchg qword ptr [r13],rbx ds:00007ff7`b81d0000=0000000100785a4d
RivenSkaye commented 11 months ago

After checking out the same commit and ensuring I was running thin LTO with lld-link (CARGO_TARGET_X86_64_PX_WINDOWS_MSVC_LINKER="lld-link" cargo +nightly-x86_64-pc-windows-msvc run --bin cube --config 'lto="thin"') I can't seem to reproduce this on latest nightly -- was this already fixed perhaps?

I've run all of the examples with the exception of the imgui one (it panics on imgui-winit-support not being upgraded and this is taking enough time already). Are there any other environment-specific things that could've caused this?

Elabajaba commented 11 months ago

I'm still able to reproduce it both on the earlier commit listed in my original post and on the latest rend3 commit (d7806f584468c4ed974a2ff5e1eea547d26478db) on rustc stable 1.74.0 (79e9716c9 2023-11-13), stable 1.74.1, and 1.76.0-nightly (3340d49d2 2023-12-12) by running the cube example with lto="thin" set in Cargo.toml (both for debug builds and release builds).

Based on how long it takes to build the final cube.exe, cargo run --bin cube --config 'lto="thin"' doesn't appear to be working on stable or nightly for me. --timings shows 0.87s to build the cube binary with --config 'lto="thin"', vs 15.75s if I add it to the Cargo.toml

[profile.dev]
lto = "thin"

That seemed long so I checked by setting lto = "fat" in Cargo.toml and it took 52.24s and the binary worked.

I removed everything in my global ~\.cargo\config.toml except

[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"

I also tested linker = "lld-link.exe" using the version of LLD included with the scoop installer llvm package (LLD 17.0.6), and it has the same issue.

RivenSkaye commented 11 months ago

Would you happen to have an MinGW env lying around? I used the lld-link.exe from there for my testing. I'll rerun things tomorrow with rust-lld to see if I can reproduce. If not, I wonder if there's some optimization step going wrong considering the system I ran this with is rather outdated

ChrisDenton commented 2 months ago

This still reproduces. Steps I took...

Firstly download the repo in the OP and switch to the indicated commit:

git clone https://github.com/BVE-Reborn/rend3.git
cd rend3
git switch --detach 4d107951a3ba62a58a7be1849eb670d05f269e20

Then I edited .cargo/config.toml to add the following (x86_64-pc-windows-msvc is both the host and target):

[target.x86_64-pc-windows-msvc]
linker = "rust-lld"

Finally run an example to see the crash:

cd examples/animation
cargo run --release

This fails with STATUS_ACCESS_VIOLATION.

I then edited the Cargo.toml in the root of the repo so to turn off optimizations but still keep lto=thin. This allowed me to capture a more detailed backtrace.

Backtrace (from windbg) ``` # Child-SP RetAddr Call Site 00 00000093`2c15d130 00007ff7`40a8d281 animation!core::sync::atomic::atomic_compare_exchange >( struct once_cell::imp::Waiter ** dst = 0x00007ff7`40580000, struct once_cell::imp::Waiter * old = 0x00000001`00785a4d, struct once_cell::imp::Waiter * new = 0x00000093`2c15d361, core::sync::atomic::Ordering success = Release (0n1), core::sync::atomic::Ordering failure = Relaxed (0n0))+0x284 [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\core\src\sync\atomic.rs @ 3391] 01 00000093`2c15d270 00007ff7`40a8dd61 animation!core::sync::atomic::AtomicPtr::compare_exchange( struct core::sync::atomic::AtomicPtr * self = 0x00007ff7`40580000, struct once_cell::imp::Waiter * current = 0x00000001`00785a4d, struct once_cell::imp::Waiter * new = 0x00000093`2c15d361, core::sync::atomic::Ordering success = Release (0n1), core::sync::atomic::Ordering failure = Relaxed (0n0))+0x31 [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\core\src\sync\atomic.rs @ 1592] 02 00000093`2c15d2d0 00007ff7`40a8db85 animation!once_cell::imp::wait( struct core::sync::atomic::AtomicPtr * queue = 0x00007ff7`40580000, struct once_cell::imp::Waiter * curr_queue = 0x00000001`00785a4d)+0xd1 [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\imp_std.rs @ 220] 03 00000093`2c15d3e0 00007ff7`414f1fdb animation!once_cell::imp::initialize_or_wait( struct core::sync::atomic::AtomicPtr * queue = 0x00007ff7`40580000)+0xa5 [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\imp_std.rs @ 202] 04 00000093`2c15d4d0 00007ff7`41501e61 animation!once_cell::imp::OnceCell >::initialize,once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec ( struct once_cell::imp::OnceCell > * self = 0x00007ff7`40580000, struct once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()> > f = struct once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()> >)+0x6b [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\imp_std.rs @ 68] 05 00000093`2c15d560 00007ff7`41501363 animation!once_cell::sync::OnceCell >::get_or_try_init,once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec ( struct once_cell::sync::OnceCell > * self = 0x00007ff7`40580000, struct once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()> > f = struct once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()> >)+0x81 [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\lib.rs @ 1161] 06 00000093`2c15d5f0 00007ff7`41500b54 animation!once_cell::sync::OnceCell >::get_or_init,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec ( struct once_cell::sync::OnceCell > * self = 0x00007ff7`40580000, struct once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()> f = struct once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()>)+0x13 [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\lib.rs @ 1120] 07 00000093`2c15d640 00007ff7`41500a2e animation!once_cell::sync::Lazy,alloc::vec::Vec (void)+0x14 [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\lib.rs @ 1313] 08 00000093`2c15d670 00007ff7`40be5b4d animation!once_cell::sync::impl$12::deref,alloc::vec::Vec ( struct once_cell::sync::Lazy,alloc::vec::Vec (*)()> * self = 0x00007ff7`40580000)+0xe [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\lib.rs @ 1377] 09 00000093`2c15d6a0 00007ff7`40be475f animation!winit::platform_impl::platform::event_loop::create_event_target_window > > >(void)+0x4d [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\winit-0.28.7\src\platform_impl\windows\event_loop.rs @ 700] 0a 00000093`2c15d7d0 00007ff7`40be247d animation!winit::platform_impl::platform::event_loop::EventLoop > > >::new > > >( struct winit::platform_impl::platform::event_loop::PlatformSpecificEventLoopAttributes * attributes = 0x00000093`2c15dbc0)+0x9f [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\winit-0.28.7\src\platform_impl\windows\event_loop.rs @ 206] 0b 00000093`2c15da80 00007ff7`40bc0c89 animation!winit::event_loop::EventLoopBuilder > > >::build > > >( struct winit::event_loop::EventLoopBuilder > > > * self = 0x00000093`2c15dbc0)+0x4d [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\winit-0.28.7\src\event_loop.rs @ 121] 0c 00000093`2c15db40 00007ff7`40bbedf2 animation!rend3_framework::App::create_window >( struct rend3_animation_example::AnimationExample * self = 0x00000093`2c15f5b0, struct winit::window::WindowBuilder * builder = 0x00000093`2c15e020)+0x59 [F:\Temp\rust\rend3\rend3-framework\src\lib.rs @ 59] 0d 00000093`2c15dda0 00007ff7`40bc8a85 animation!rend3_framework::async_start::async_fn$0 >(void)+0x222 [F:\Temp\rust\rend3\rend3-framework\src\lib.rs @ 206] 0e 00000093`2c15f340 00007ff7`40bc0f11 animation!pollster::block_on > > >( union enum2$ > > * fut = 0x00000093`2c15f460 Unresumed)+0xc5 [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\pollster-0.3.0\src\lib.rs @ 128] 0f 00000093`2c15f440 00007ff7`40bcaa01 animation!rend3_framework::start >( struct rend3_animation_example::AnimationExample app = , struct winit::window::WindowBuilder window_builder = )+0x21 [F:\Temp\rust\rend3\rend3-framework\src\lib.rs @ 419] 10 00000093`2c15f660 00007ff7`40583ac9 animation!rend3_animation_example::main(void)+0xa1 [F:\Temp\rust\rend3\examples\animation\src\lib.rs @ 198] 11 00000093`2c15fa60 00007ff7`40583a8b animation!animation::main(void)+0x9 [F:\Temp\rust\rend3\examples\animation\src\main.rs @ 3] 12 00000093`2c15fa90 00007ff7`40583aae animation!core::ops::function::FnOnce::call_once * f = 0x00007ff7`40583ac0)+0xe [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\std\src\sys\backtrace.rs @ 155] 15 00000093`2c15fb10 00007ff7`40cc3085 animation!std::rt::lang_start::closure$0 >(void)+0x11 [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\std\src\rt.rs @ 162] 16 00000093`2c15fb50 00007ff7`405839ca animation!std::rt::lang_start_internal(void)+0x95 [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\rt.rs @ 141] 17 00000093`2c15fca0 00007ff7`40583ae9 animation!std::rt::lang_start >( * main = 0x00007ff7`40583ac0, int64 argc = 0n1, unsigned char ** argv = 0x00000208`076f0cf0, unsigned char sigpipe = 0x00 '')+0x3a [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\std\src\rt.rs @ 161] 18 00000093`2c15fd10 00007ff7`4150c0c0 animation!main+0x19 19 (Inline Function) --------`-------- animation!invoke_main(void)+0x22 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] 1a 00000093`2c15fd40 00007ffe`35d9257d animation!__scrt_common_main_seh(void)+0x10c [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 1b 00000093`2c15fd80 00007ffe`377eaf28 KERNEL32!BaseThreadInitThunk+0x1d 1c 00000093`2c15fdb0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 ```

This points to using atomic_compare_exchange from once_cell but I think things start going wrong earlier in winit. Specifically: https://github.com/rust-windowing/winit/blob/2ebbfab6a47f93f76841553dcb3cc53683e4955c/src/platform_impl/windows/event_loop.rs#L700

lpszClassName: THREAD_EVENT_TARGET_WINDOW_CLASS.as_ptr(),

THREAD_EVENT_TARGET_WINDOW_CLASS is defined as:

static THREAD_EVENT_TARGET_WINDOW_CLASS: Lazy<Vec<u16>> =
    Lazy::new(|| util::encode_wide("Winit Thread Event Target"));

So my assumption is the static isn't getting linked correctly for some reason.

Maybe.... @lqd do you have any ideas?

ChrisDenton commented 2 months ago

Ok I've minimized it a bit more and realised that the crate-type in Cargo.toml seems to play a role. I need both "lib" and "cdylib" for this problem to occur.

[lib]
crate-type = ["lib", "cdylib"]

My minimization so far:

# Cargo.toml
[package]
name = "winit_test"
version = "0.1.0"
edition = "2021"

[[bin]]
name = "animation"
path = "src/main.rs"

[lib]
crate-type = ["lib", "cdylib"]

[profile.dev]
lto = "thin"

[dependencies]
winit = "0.28"
# .cargo/config.toml
[target.x86_64-pc-windows-msvc]
linker = "rust-lld
// src/main.rs
fn main() {
    winit_test::main();
}
// src/lib.rs
use winit::event_loop::{EventLoop, EventLoopBuilder};

pub fn main() {
    let _event_loop: EventLoop<u8> = EventLoopBuilder::with_user_event().build();
}

Doing cargo run results in:

error: process didn't exit successfully: `target\debug\animation.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
backtrace ``` # Child-SP RetAddr Call Site 00 0000005a`ea97ee00 00007ff6`f6a5d421 animation!core::sync::atomic::atomic_compare_exchange >( struct once_cell::imp::Waiter ** dst = 0x00007ff6`f6a50000, struct once_cell::imp::Waiter * old = 0x00000001`00785a4d, struct once_cell::imp::Waiter * new = 0x0000005a`ea97f031, core::sync::atomic::Ordering success = Release (0n1), core::sync::atomic::Ordering failure = Relaxed (0n0))+0x284 [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\core\src\sync\atomic.rs @ 3391] 01 0000005a`ea97ef40 00007ff6`f6a5e3e1 animation!core::sync::atomic::AtomicPtr::compare_exchange( struct core::sync::atomic::AtomicPtr * self = 0x00007ff6`f6a50000, struct once_cell::imp::Waiter * current = 0x00000001`00785a4d, struct once_cell::imp::Waiter * new = 0x0000005a`ea97f031, core::sync::atomic::Ordering success = Release (0n1), core::sync::atomic::Ordering failure = Relaxed (0n0))+0x31 [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\core\src\sync\atomic.rs @ 1592] 02 0000005a`ea97efa0 00007ff6`f6a5e1fe animation!once_cell::imp::wait( struct core::sync::atomic::AtomicPtr * queue = 0x00007ff6`f6a50000, struct once_cell::imp::Waiter * curr_queue = 0x00000001`00785a4d)+0xd1 [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\imp_std.rs @ 220] 03 0000005a`ea97f0b0 00007ff6`f6a96e5b animation!once_cell::imp::initialize_or_wait( struct core::sync::atomic::AtomicPtr * queue = 0x00007ff6`f6a50000)+0xbe [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\imp_std.rs @ 202] 04 0000005a`ea97f1a0 00007ff6`f6a98a51 animation!once_cell::imp::OnceCell >::initialize,once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec ( struct once_cell::imp::OnceCell > * self = 0x00007ff6`f6a50000, struct once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()> > f = struct once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()> >)+0x6b [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\imp_std.rs @ 68] 05 0000005a`ea97f230 00007ff6`f6a98383 animation!once_cell::sync::OnceCell >::get_or_try_init,once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec ( struct once_cell::sync::OnceCell > * self = 0x00007ff6`f6a50000, struct once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()> > f = struct once_cell::sync::impl$6::get_or_init::closure_env$0,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()> >)+0x81 [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\lib.rs @ 1161] 06 0000005a`ea97f2c0 00007ff6`f6a97d94 animation!once_cell::sync::OnceCell >::get_or_init,once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec ( struct once_cell::sync::OnceCell > * self = 0x00007ff6`f6a50000, struct once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()> f = struct once_cell::sync::impl$11::force::closure_env$0,alloc::vec::Vec (*)()>)+0x13 [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\lib.rs @ 1120] 07 0000005a`ea97f310 00007ff6`f6a9180e animation!once_cell::sync::Lazy,alloc::vec::Vec (void)+0x14 [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\lib.rs @ 1313] 08 0000005a`ea97f340 00007ff6`f6aa92bd animation!once_cell::sync::impl$12::deref,alloc::vec::Vec ( struct once_cell::sync::Lazy,alloc::vec::Vec (*)()> * self = 0x00007ff6`f6a50000)+0xe [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\once_cell-1.19.0\src\lib.rs @ 1377] 09 0000005a`ea97f370 00007ff6`f6aa8aff animation!winit::platform_impl::platform::event_loop::create_event_target_window(void)+0x4d [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\winit-0.28.7\src\platform_impl\windows\event_loop.rs @ 700] 0a 0000005a`ea97f4a0 00007ff6`f6aa8a0d animation!winit::platform_impl::platform::event_loop::EventLoop::new( struct winit::platform_impl::platform::event_loop::PlatformSpecificEventLoopAttributes * attributes = 0x0000005a`ea97f870)+0x9f [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\winit-0.28.7\src\platform_impl\windows\event_loop.rs @ 206] 0b 0000005a`ea97f750 00007ff6`f6aade92 animation!winit::event_loop::EventLoopBuilder::build( struct winit::event_loop::EventLoopBuilder * self = 0x0000005a`ea97f870)+0x4d [F:\Programs\rust-lang\Cargo\registry\src\index.crates.io-6f17d22bba15001f\winit-0.28.7\src\event_loop.rs @ 121] 0c 0000005a`ea97f810 00007ff6`f6a51149 animation!winit_test::main(void)+0x32 [F:\Temp\rust\mvp\src\lib.rs @ 4] 0d 0000005a`ea97f8a0 00007ff6`f6a5111b animation!animation::main(void)+0x9 [F:\Temp\rust\mvp\src\main.rs @ 3] 0e 0000005a`ea97f8d0 00007ff6`f6a5108e animation!core::ops::function::FnOnce::call_once * f = 0x00007ff6`f6a51140)+0xe [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\std\src\sys\backtrace.rs @ 155] 11 0000005a`ea97f950 00007ff6`f6a70135 animation!std::rt::lang_start::closure$0 >(void)+0x11 [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\std\src\rt.rs @ 162] 12 0000005a`ea97f990 00007ff6`f6a5103a animation!std::rt::lang_start_internal(void)+0x95 [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\rt.rs @ 141] 13 0000005a`ea97fae0 00007ff6`f6a51169 animation!std::rt::lang_start >( * main = 0x00007ff6`f6a51140, int64 argc = 0n1, unsigned char ** argv = 0x00000255`2c566550, unsigned char sigpipe = 0x00 '')+0x3a [/rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\std\src\rt.rs @ 161] 14 0000005a`ea97fb50 00007ff6`f6aae270 animation!main+0x19 15 (Inline Function) --------`-------- animation!invoke_main(void)+0x22 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] 16 0000005a`ea97fb80 00007ffe`35d9257d animation!__scrt_common_main_seh(void)+0x10c [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 17 0000005a`ea97fbc0 00007ffe`377eaf28 KERNEL32!BaseThreadInitThunk+0x1d 18 0000005a`ea97fbf0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 ```
lqd commented 2 months ago

I need both "lib" and "cdylib" for this problem to occur.

I also believe this is the key factor, we have other similar issues (involving LTO and PGO, creating invalid LLVM modules; I’ll find them when I’m back at a computer) triggered by this cargo setting/behavior.

(I do wonder if this issue reproduces with zoxc’s recent PRs though (a revert and an _imp fix that lld needs but not link.exe))

ChrisDenton commented 2 months ago

Thanks! It seems like https://github.com/rust-lang/rust/pull/129079/commits/713a006d4b8983bd8b246255542cacc073bc8590 fixes it on my local machine.