From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) by sourceware.org (Postfix) with ESMTPS id B88213858412 for ; Tue, 7 Sep 2021 03:34:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B88213858412 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=systematicsw.ab.ca Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id NHQgmAszMczbLNRsQmLpbl; Tue, 07 Sep 2021 03:34:26 +0000 Received: from [192.168.1.105] ([68.147.0.90]) by cmsmtp with ESMTP id NRsQmRqT3U9pxNRsQmMkVc; Tue, 07 Sep 2021 03:34:26 +0000 X-Authority-Analysis: v=2.4 cv=Bbi7bph2 c=1 sm=1 tr=0 ts=6136ddc2 a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=2QSLavsyAAAA:8 a=uYT-Tk0qkVT609LjNaIA:9 a=QEXdDO2ut3YA:10 a=9H_80fVQ3bbXSWzY4Kdq:22 Reply-To: cygwin@cygwin.com Subject: Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?] To: cygwin@cygwin.com 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> <5b705ae7c9747a9cc25d2610cc6748e92bbe1d70.camel@dontech.dk> <890dad21-dec5-cdd1-bf99-bdb45e759a71@cornell.edu> From: Brian Inglis Organization: Systematic Software Message-ID: <742331ee-4d9f-e86f-9314-c85b5f0cbfa8@SystematicSw.ab.ca> Date: Mon, 6 Sep 2021 21:34:25 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <890dad21-dec5-cdd1-bf99-bdb45e759a71@cornell.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfAvZtSLsCgGS2ugtwMfloCbFVomM2+eb9VS4Z/iEmtQvZRd+u+JXAdm2tyWRPyFTMj4dCpdHhyJfRbY6BU6IJzBV5hEonTAVCRoeADN0vr+VpgmeILAX x7AO1Gbei10IRVYDzkZbr7UMvhDdqhpPD3lAQlTgGyk5Z4LJWC79LqrLXst1yCxGK3TQa7wZkgMc6uAq26++yZ6yDwXh4uutF8A= X-Spam-Status: No, score=-1166.1 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: Tue, 07 Sep 2021 03:34:29 -0000 On 2021-09-06 15:24, Ken Brown via Cygwin wrote: > On 9/6/2021 4:54 PM, Peter Dons Tychsen wrote: >> 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. > > You're looking at the wrong source code.  The bug didn't occur until the > code was changed to do the following: > >       /* g++ 11.2 workaround: don't use initializer */ >       MEM_EXTENDED_PARAMETER mmap_ext; >       mmap_ext.Type = MemExtendedParameterAddressRequirements; >       mmap_ext.Pointer = (PVOID) &mmap_req; > > This left mmap_ext.Reserved uninitialized, which Corinna has now fixed. With undocumented structure member initialization an issue, maybe better to future proof using e.g. MEM_EXTENDED_PARAMETER mmap_ext = { 0 }; // or memset or bzero ... -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]