From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.smtp.larsendata.com (mx1.smtp.larsendata.com [91.221.196.215]) by sourceware.org (Postfix) with ESMTPS id 8313F3857C60 for ; Mon, 6 Sep 2021 20:54:39 +0000 (GMT) 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 Received: from mail01.mxhotel.dk (mail01.mxhotel.dk [91.221.196.236]) by mx1.smtp.larsendata.com (Halon) with ESMTPS id 9edda035-0f54-11ec-a02a-0050568c148b; Mon, 06 Sep 2021 20:54:25 +0000 (UTC) Received: from [10.0.0.80] (unknown [94.147.60.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: pdt@dontech.dk) by mail01.mxhotel.dk (Postfix) with ESMTPSA id 11600194CF3; Mon, 6 Sep 2021 22:54:27 +0200 (CEST) Message-ID: <5b705ae7c9747a9cc25d2610cc6748e92bbe1d70.camel@dontech.dk> Subject: Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?] X-Report-Abuse-To: abuse@mxhotel.dk From: Peter Dons Tychsen To: Ken Brown , cygwin@cygwin.com Date: Mon, 06 Sep 2021 22:54:35 +0200 In-Reply-To: <3a63eb8c-3e8e-cd2c-b9de-8c34fa041a75@cornell.edu> References: <88fde5d5-4897-8792-576a-a62be0092ad8@cornell.edu> <94b5b6cf-1670-cbdd-2f51-84dae09d27b6@cornell.edu> <387d9062-1ff9-6eab-e268-e5070352a193@cornell.edu> <40275f71-7c10-55a9-e6c8-a948e32c37ac@cornell.edu> <33ae27cb-4e45-7484-40d1-6cbd88c958f1@cornell.edu> <3a63eb8c-3e8e-cd2c-b9de-8c34fa041a75@cornell.edu> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 20:54:42 -0000 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