search

Windfisch / rust-assert-no-alloc

Custom Rust allocator allowing to temporarily disable memory (de)allocations for a thread. Aborts or prints a warning if allocating although forbidden.
Other
44 stars 9 forks source link

applications don't start with x86_64-pc-windows-gnu #7

Open Be-ing opened 2 years ago

Be-ing commented 2 years ago

Investigating the feasibility of cross compiling my application from Linux to Windows to find out if I'll need Windows for CI, I tried building for the x86_64-pc-windows-gnu target and running the executable in my Windows VM. However, my application just hangs on startup. Even putting println! as the very first line of main does nothing. When I commented out setting the global allocator to AllocDisabler, it worked both in my Windows VM and WINE.

Be-ing commented 2 years ago

Guarding the #[global_allocator] with #[cfg(not(all(windows, target_env = "gnu")))] hacks around the problem. Of course that isn't great if you're doing development with MinGW.

robbert-vdh commented 2 years ago

I also noticed this issue a while back when cross compiling libraries to x86_64-pc-windows-gnu and running them under Wine, but I assumed this not working was just the result of the combination of those two factors and didn't look into it much further. But as it turns out the same thing happens when you compile and run x86_64-pc-windows-gnu binaries/libraries on native Windows. Has anyone looked into this yet?

Be-ing commented 2 years ago

Indeed this bug is reproducible running both with WINE and Windows.

Windfisch commented 2 years ago

Uh, this is weird. Have you tried attaching a debugger to this so you see where exactly it is hanging? Does it hog the CPU or is it just idle?

I don't have a windows system around to test, but can you maybe provide a concrete example how to reproduce this bug under linux/wine? (Including how you set up wine and rust under wine)? Maybe winedbg can help...

robbert-vdh commented 2 years ago

It happens on the first allocation. So presumably a program that just creates a Box<u32> and dbg!() prints it should hang. You can cross compile to the x86_64-pc-windows-gnu target on Linux and run the binary under Wine with winedbg --gdb.