DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 54N5Neh1751670
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 54N5Neh1751670
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=J6WBy+F8
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 72A403857738
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1747977818;
	bh=sFBeuuNS5DVKGZ1MA6S+igvr1q+74TCOhBB6vIWHO44=;
	h=Date:To:cc:Subject:In-Reply-To:References:List-Id:
	List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	From:Reply-To:From;
	b=J6WBy+F80rc4EdsAUtLDMSH6VvWJSptVnA1LNshrQUGX844XJHS78iBk57f5cY41d
	iCuStY/tNsEbF3DixQ1Z65tPDotDnUV+BQdj3US09ijFVAcaJDop2qvHxGirb70OX8
	e5X6ocBH4bXAqB7CJu9gkR1LWy28GFwm6C462AQc=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 4C9063857BBA
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 4C9063857BBA
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1747977753; cv=none;
	b=urKlYiZoOptkcrqncLalzf0z6IiMZ2eROmogEDrOPEx4QVZVvYqqNB2XBE6Bm52sOY1m3S70ZUT6LS/d1BpD8xnWdABW4yxrBT9E/T8Ag8qkaA/WPqv4O4LvvsSFj7GgJ9bGczf3dNJThDvSD3uj7Cdt+wca2Zg50H21nJJJW38=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1747977753; c=relaxed/simple;
	bh=VLIAnGgR5pqPCq1DUfpBy7L+ErWEYZEoMjv8lwcRz6k=;
	h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;
	b=wP9935LEToBEcl9QMWIAv8pGtzqD3x0RrVC7VS2UiisP7VtpYWNy6ZliyHw00CsUVds3/8aZFqkApiMA+ZcMggOouta3S7xyL9CXX4tCq2QYBY0x6XjozlcfhSJ/vvGD6oLlLq4/R3JfEhXnlSm56tR4BiAxLFAQcEQhFb2F0h8=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 4C9063857BBA
Date:	Thu, 22 May 2025 22:22:32 -0700 (PDT)
X-X-Sender:	jeremyd AT resin DOT csoft DOT net
To:	Yuyi Wang <Strawberry_Str AT hotmail DOT com>
cc:	cygwin AT cygwin DOT com
Subject:	Re: fork error when trying to call VirtualAlloc with size==0
In-Reply-To:	<TYCPR01MB1092660CCD0F71A65942C14AAF898A@TYCPR01MB10926.jpnprd01.prod.outlook.com>
Message-ID:	<cb1b7e88-5d92-8b14-149c-701352594786@jdrake.com>
References:	<58358b38-9bdc-0f7b-7f65-fb158147abdf AT jdrake DOT com>
	<TYCPR01MB1092660CCD0F71A65942C14AAF898A AT TYCPR01MB10926 DOT jpnprd01 DOT prod DOT outlook DOT com>
MIME-Version:	1.0
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Jeremy Drake via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Jeremy Drake <cygwin AT jdrake DOT com>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

On Fri, 23 May 2025, Yuyi Wang 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.

No, these retries are done on fork in the child, before control is
returned to the caller of fork.

> Could this issue be solved by running rebaseall on binaries in
> `/usr/bin`? Should we introduce `rebase` to rustc?

Maybe.  MSYS2 doesn't generally advise to rebase on x86_64, but I think
Cygwin does as part of its setup/postinstall hooks.  As a hack, I was able
to work around this by setting the "dynamicbase" flag on the dlls (it's a
long story about why this helps rather than hurts in this particular case)

> 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.
>
> 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.

posix_spawn currently does fork+exec under the hood.  It's on my TODO list
to try to optimize this to do a "spawn" instead in cases where the
attributes and file actions are not too complicated.  While I had this
situation in the debugger, I confirmed this case is going through
posix_spawnp, with all of the attributes fields 0, and 2 file actions
which are dup2s for stdout and stderr.  This should be perfectly fine to
implement through the ch_spawn worker, though no ability is currently
exposed through it to redirect stderr it is possible to do so through the
win32 apis so it's just a matter of exposing it in the internal api.

I was thinking today about trying to hack something together to do this,
but I don't know when I'll get time to do this, and for a real
implementation rather than a proof-of-concept hack I'd want to ask some
questions of Corinna on the best way forward.

Namely: the posix_spawn_file_actions_t and posix_spawnattr_t structs are
defined inside newlib/libc/posix/spawn.c.  While there seem to be
'getters' for the attrs, I don't see any public way to query the file
actions.

My plan was to make functions cygwin_posix_spawn and cygwin_posix_spawnp,
and redirect the exports in cygwin.din to these functions, and inspect the
parameters and decide if they were something that was easily doable with
ch_spawn or if we should forward the call to the original functions from
newlib to do fork/exec.  The issue is that these functions would need to
look at the file actions.  For a proof-of-concept I would copy/paste the
file actions structs from newlib, but I don't know what the best option
would be for doing so in a maintainable way.  Something to think about...

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -