DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 54NBdaPC976037
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 54NBdaPC976037
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=wAtmZPD6
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A2BE03857359
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1748000374;
	bh=v5NJf59j/Quw7kfH6QRquaUvzfEp/h52OM1vu+Vy5+E=;
	h=Date:Subject:To:References:Cc:In-Reply-To:List-Id:
	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	 From:Reply-To:From;
	b=wAtmZPD6cLEiwxJSKUTYoOwIVI44mGj7MiXqguAu4z4nWCMQswz9wwypHkWZ9pbjj
	 wAWoUChfaLyLnHUf83twZPbCQuqDOBCuiiqdZvYePO1Tk8urMVDhqmODd43sQI8hNv
	 P4Jg6T2NC7YjjIicnr1mVujlH3/glem+P7ljcKpU=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C708D3857BBA
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C708D3857BBA
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1747999890; cv=none;
 b=FL7w7uT4S2p1rrGqhGCLlVZ3S4vf4pLiX88hYysDhEn2yL+FmNpYjUVp/gcTe/Abev0N9jPrM4xkb8dWr1fk2zxSH1O5fdEfSTt2+XKzNEVqidkXrIyvK7iyrIwEgGbOPLKEf877blFcWw+E0dphf3nT0ViLHPbItAAqoJ5hdys=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1747999890; c=relaxed/simple;
 bh=Ykzg6YKY0he0Z7fmxDFLZmegkzpl44SoHwftdG5gKzc=;
 h=Message-ID:Date:MIME-Version:Subject:To:From;
 b=AjbBvnOd+5ynEizb8L9J0MXxwDS2aDtM/QAnY8EspN/M2BFDYU+KtG1qRDBVGib7fEyWVI2CqkMmImHFeF/PMiO/Ypeey0meZS3OkLP3Njl5vfzcoOgJx7mprr0bN7J5YNPhsF2b9UOyg2DNVzu1tta980Bt/VlQJXsc1cWVvKw=
ARC-Authentication-Results: i=1; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C708D3857BBA
X-SNCR-Rigid: 67D89E7C0771A7FD
X-Originating-IP: [81.129.146.154]
X-OWM-Source-IP: 81.129.146.154
X-OWM-Env-Sender: jon DOT turney AT dronecode DOT org DOT uk
X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdekjeegucdltddurdegfedvrddttddmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhepkfffgggfuffvfhfhvegjtgfgsehtjeertddtvdejnecuhfhrohhmpeflohhnucfvuhhrnhgvhicuoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqeenucggtffrrghtthgvrhhnpeevvdekgfffteetueehgfdugefgkeevleejudduheevuedtveejfeevvdevvdfgvdenucfkphepkedurdduvdelrddugeeirdduheegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurddutdelngdpihhnvghtpeekuddruddvledrudegiedrudehgedpmhgrihhlfhhrohhmpehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkpdhrvghvkffrpehhohhsthekuddquddvledqudegiedqudehgedrrhgrnhhgvgekuddquddvledrsghttggvnhhtrhgrlhhplhhushdrtghomhdprghuthhhpghushgvrhepjhhonhhtuhhrnhgvhiessghtihhnthgvrhhnvghtrdgtohhmpdhgvghokffrpefiuedpoffvtefjohhsthepsghtphhrughrghhotdduvddpnhgspghrtghpthhtohepfedprhgtphhtthhopefuthhrrgifsggvrhhrhigpufhtrheshhhothhmrghilhdr
 tghomhdprhgtphhtthhopegthihgfihinhestgihghifihhnrdgtohhmpdhrtghpthhtoheptgihghifihhnsehjughrrghkvgdrtghomh
X-RazorGate-Vade-Verdict: clean 0
X-RazorGate-Vade-Classification: clean
X-VadeSecure-score: verdict=clean score=0/300, class=clean
Message-ID: <02d6356a-107f-4a1d-b891-0a466e625d89@dronecode.org.uk>
Date: Fri, 23 May 2025 12:31:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: fork error when trying to call VirtualAlloc with size==0
To: Yuyi Wang <Strawberry_Str AT hotmail DOT com>, Jeremy Drake <cygwin AT jdrake DOT com>
References: <58358b38-9bdc-0f7b-7f65-fb158147abdf AT jdrake DOT com>
 <TYCPR01MB1092660CCD0F71A65942C14AAF898A AT TYCPR01MB10926 DOT jpnprd01 DOT prod DOT outlook DOT com>
Content-Language: en-US
Cc: cygwin AT cygwin DOT com
In-Reply-To: <TYCPR01MB1092660CCD0F71A65942C14AAF898A@TYCPR01MB10926.jpnprd01.prod.outlook.com>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
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: Jon Turney via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Jon Turney <jon DOT turney AT dronecode DOT org DOT uk>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 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.


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