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 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
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
Subject: Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow
 -- throttled?]
To: cygwin AT cygwin DOT com
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>
 <5b705ae7c9747a9cc25d2610cc6748e92bbe1d70 DOT camel AT dontech DOT dk>
 <890dad21-dec5-cdd1-bf99-bdb45e759a71 AT cornell DOT edu>
From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
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-Language: en-CA
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 AT cygwin DOT com
X-Mailman-Version: 2.1.29
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>
Reply-To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset="utf-8"; 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>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 1873Z8Zj014119

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

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