fork error when trying to call VirtualAlloc with size==0

[Jon Turney]

On 23/05/2025 02:59, Yuyi Wang via Cygwin wrote:
> On Wed, 22 May 2025, Jeremy Drake wrote:
>> Ultimately, playing whack-a-mole in a 64-bit address space hoping that the
>> DLL will load in the same place as the parent is an exercise in futility,
>> especially in only 6 attempts.
> 
> Outside cygwin, rustc also try 5 times to load the proc macro DLL, so there are
> 30 attempts. Could this issue be solved by running rebaseall on binaries in
> `/usr/bin`? Should we introduce `rebase` to rustc?
> 
> Another idea: is it possible to provide an API to disable reload-on-fork of a
> specific DLL? Although it might be unsafe, I think it's OK here, because rustc
> just wants to execute the linker, and in this case the proc macro DLLs won't be
> used in the new process.

You might want to check that the ld flag '--enable-auto-image-base' is 
being used here (it's our gcc specsfile, but idk if you are doing 
something unusual here)

(otherwise all DLLs end up with the default ImageBase address and you'll 
end up with collisions for certain, which we are at the mercy of how the 
Windows loader chooses to resolve)

> In rust-lang/rust#141276, Jeremy Drake wrote:
>> It seems like in most cases it'd probably use posix_spawn
> 
> If I were right, posix_spawn also uses fork + exec. That's why I don't think
> switching to `Command::spawn` would solve this problem. However, the non-POSIX
> spawn* APIs don't use fork. I'm not sure if it worth a try. As it seems that the
> linker is executed by LLVM, I think it may be better to patch LLVM.