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 4DC23385701B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cs.umass.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.umass.edu Subject: Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?] To: cygwin AT cygwin DOT com References: <72F25EBC-6801-4C96-8F6C-48F09B25B712 AT house DOT org> <6105153B-D145-449D-97FE-D6F17BEB2032 AT house DOT org> <6beb1156-931e-0380-ee60-2ca519f49a2f 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> <33ae27cb-4e45-7484-40d1-6cbd88c958f1 AT cornell DOT edu> From: Eliot Moss Message-ID: <6537bf27-e5e2-56a9-a503-90ec3274a20e@cs.umass.edu> Date: Mon, 6 Sep 2021 13:43:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <33ae27cb-4e45-7484-40d1-6cbd88c958f1@cornell.edu> Content-Language: en-US X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: moss AT cs DOT umass DOT edu Content-Type: text/plain; charset="windows-1252"; Format="flowed" Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id 186HhqmG013206 On 9/6/2021 1:38 PM, Ken Brown via Cygwin wrote: > On 9/6/2021 1:12 PM, Ken Brown via Cygwin wrote: >> On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote: >>> On Sep  5 09:24, Ken Brown via Cygwin wrote: >>>> On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote: >>>>> On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote: >>>>>> Here are the correct commits: >>>>>> >>>>>> 8169e39ab Cygwin: C++17: register keyword is deprecated >>>>>> 3ca80b360 Cygwin: dumper: fix up GCC pragma for g++ 11.2 >>>>>> bdb7991db Cygwin: workaround a g++ 11.2 initialization bug >>>>>> 801120c1f Cygwin: loader script: add DWARF 5 sections >>>>>> d5cc66426 Cygwin: testsuite: avoid "conflicting types" gcc warning >>>>>> c2fe205b5 strstr: avoid warnings >>>>>> 76c2c7a89 ldexp/ldexpf: avoid assembler warning >>>>>> eeeb5650c Cygwin: fix declaration of RtlInitEmptyUnicodeString >>>>>> >>>>>>> >>>>>>>> So there appears to be something wrong with cygwin1.dll >>>>>>>> built with the current build tools (gcc 11.2.0, binutils >>>>>>>> 2.37, not sure what else is relevant). >>>>> >>>>> Wait a minute...I'll bet this is related to the MEM_EXTENDED_PARAMETER >>>>> initialization problem that was dealt with in commit bdb7991db. >>>> >>>> More data: When I run the test case under gdb, it succeeds.  When I run it >>>> under strace, I see VirtualAlloc2 in fhandler_dev_zero::mmap failing with >>>> windows error 87. >>> >>> Are the const's I added to the MEM_EXTENDED_PARAMETER data invalid, >>> perhaps? >> >> I tried removing them, and I got the same error.  I also tried removing static, and I tried >> removing both static and const. > > BTW, when I reported that the test case succeeds under gdb, that only happens when I build the test > case without optimization.  If I build with -O2, it fails under gdb also.  [In all my tests, I built > cygwin1.dll without optimization.] This makes no sense to me at all. There can be a number of possibilities, but I wonder about a variable uninitialized along some path. By accident, the contents may have a non-failing value with -O0 by the situation can be different for -O2. If you're dealing with concurrency and such, then -O0 and -O2 can act differently with respect to races. Just some thoughts ... Best - Eliot Moss -- 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