X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.1 sourceware.org 8313F3857C60
Authentication-Results:	sourceware.org;
	dmarc=none (p=none dis=none) header.from=dontech.dk
Authentication-Results:	sourceware.org; spf=none smtp.mailfrom=dontech.dk
Message-ID:	<5b705ae7c9747a9cc25d2610cc6748e92bbe1d70.camel@dontech.dk>
Subject:	Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow
	-- throttled?]
X-Report-Abuse-To:	abuse AT mxhotel DOT dk
From:	Peter Dons Tychsen <pdt AT dontech DOT dk>
To:	Ken Brown <kbrown AT cornell DOT edu>, cygwin AT cygwin DOT com
Date:	Mon, 06 Sep 2021 22:54:35 +0200
In-Reply-To:	<3a63eb8c-3e8e-cd2c-b9de-8c34fa041a75@cornell.edu>
References:	<YTJ9wwbHqeoGxZMP AT calimero DOT vinschen DOT de>
	<c54c8815-44fe-a837-211e-6497a185c2e8 AT cornell DOT edu>
	<88fde5d5-4897-8792-576a-a62be0092ad8 AT cornell DOT edu>
	<94b5b6cf-1670-cbdd-2f51-84dae09d27b6 AT cornell DOT edu>
	<387d9062-1ff9-6eab-e268-e5070352a193 AT cornell DOT edu>
	<40275f71-7c10-55a9-e6c8-a948e32c37ac AT cornell DOT edu>
	<YTY0oN9x7wNtJAKx AT calimero DOT vinschen DOT de>
	<d3c9bb17-b859-e7b1-d7e6-c421d0f37836 AT cornell DOT edu>
	<33ae27cb-4e45-7484-40d1-6cbd88c958f1 AT cornell DOT edu>
	<YTZXGlvWWUk23bJI AT calimero DOT vinschen DOT de>
	<YTZY/vytb7nagC6M AT calimero DOT vinschen DOT de>
	<3a63eb8c-3e8e-cd2c-b9de-8c34fa041a75 AT cornell DOT edu>
User-Agent:	Evolution 3.38.4 (3.38.4-1.fc33)
MIME-Version:	1.0
X-Spam-Status:	No, score=-1.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE,
	TXREP autolearn=no autolearn_force=no version=3.4.4
X-Spam-Checker-Version:	SpamAssassin 3.4.4 (2020-01-24) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
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>
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>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 186KtIIw014989

Hi there,

On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
> > No, wait.  I get what you say.  The optimzation settings of the test
> > case should have no influence on the code inside the DLL.  That
> > doesn't
> > make sense for sure.  However, I ran the testcase under GDB, I could
> > reproduce the issue, and I could fix it by setting mmap_ext.Reserved
> > = 0;
> > Go figure!
> 
> I don't get it, but I can confirm that the problem is fixed.

That sounds a bit like a voodoo fix, that could quickly regress again.

Here is my 2 cents:

Currently the mmap_ext structure is setup like this:

 215       MEM_EXTENDED_PARAMETER mmap_ext = {
 216         .Type = MemExtendedParameterAddressRequirements,
 217         .Pointer = (PVOID) &mmap_req
 218       };

This means that all other entries in the struct are zero at
initialization as described here:
https://en.cppreference.com/w/c/language/struct_initialization

So if you set "mmap_ext.Reserved = 0" again after that its a double
failure. 

1) The compiler should ignore it as it is redundent.
2) It makes no sense, as it is already zero :-)

Since it is not ignored, the compiler clearly puts in code to to
reinitialize the variable (which some compilers do not optimize for).

The reason this makes it "work" it probably because of some other stack
curruption that is going on which then disappears because of the code
moving around a bit due to the new line. My best guess would be that
other fun stuff in the same location would also "fix" the problem.

These are not the droids you are looking for. The real problem is
elsewhere, and is likely due to some stack-smashing going on. This is
also likely why recompiling the test program makes a difference as that
changes what goes on the variable stack. When the code moves around
again (e.g. new compiler version), it could break again.

Looking at the test program -02 vs -O0:

pushq	%rbp
.seh_pushreg	%rbp
movq	%rsp, %rbp
.seh_setframe	%rbp, 0
subq	$64, %rsp
.seh_stackalloc	64
.seh_endprologue

vs

subq	$56, %rsp
.seh_stackalloc	56

Which gives a different stack layout. I think the problem must be in
the start of mmap() or subsequent calls like CreateMapping() and
MapView(). Something smashes or affects the stack.

Thanks,

/pedro


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