From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) by sourceware.org (Postfix) with ESMTPS id 528A83858D32 for ; Mon, 16 Jan 2023 19:23:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 528A83858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=Shaw.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=shaw.ca Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id HPpQpCVZOl2xSHV55pKv1J; Mon, 16 Jan 2023 19:23:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shaw.ca; s=s20180605; t=1673897023; bh=is5wwzrEMU/5fjFhkViW65AoFkQnerwpO8cSPyU0uXY=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=TwbcmZeVS8aIL3SlSkirAQdkDXHjofiO/AleU2LkB5C2gaYTm33OUPke2Pv7G8VMP RklhLZyuRWy7YpBliOdDzBR+O0cMP7AqBMfroNL2XC/plg+gluQhBgczz9aYFeZuqB 0eH6t9pNNTXVdfJj0yKhrvzU8hQCzo/xxIw1fyBZXSrJPSvychCjJOGBmzwANDa+9S PdOlm2CISfrkK/NuhfS/pLh4HGHn3ASqVmA5N8bvmOKbn21xxW1lgBtlaeippJiA+J AqgsVTJYF3MjdyOmQubMk/L31Y9xGJFUaJWlUSq8fz0+XJoBMMcqYNGsK9fFQ97zP1 nv7Cv20YJAG0Q== Received: from [10.0.0.5] ([184.64.124.72]) by cmsmtp with ESMTP id HV55pC9Bb3fOSHV55pTOnY; Mon, 16 Jan 2023 19:23:43 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=63c5a43f a=oHm12aVswOWz6TMtn9zYKg==:117 a=oHm12aVswOWz6TMtn9zYKg==:17 a=IkcTkHD0fZMA:10 a=h9tPzEjHfjXqG23pXWwA:9 a=QEXdDO2ut3YA:10 Message-ID: <40dfd7b0-9b90-6c0d-fb05-85b68ec60544@Shaw.ca> Date: Mon, 16 Jan 2023 12:23:43 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Reply-To: cygwin@cygwin.com Subject: Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/... Content-Language: en-CA To: cygwin@cygwin.com References: <4a4427cc-422b-1d14-015e-26523e620d9b@Shaw.ca> <20230102113201.476c10bef7a5643bddc00762@nifty.ne.jp> <20230102143803.53f89d07a545a1bdd596e1e8@nifty.ne.jp> <20230102172147.83789d400bb0400cb8c8ca74@nifty.ne.jp> <20230116180213.0e03a896f512d784933f54da@nifty.ne.jp> <20230116234532.f567e64fe7bf9a0a13704af9@nifty.ne.jp> From: Brian Inglis Organization: Inglis In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfFCZS6/pHuMAqUnJhgw0LFY95QAkEPYXKSgTCcRVFX04EhSGEaaAaRoNl/A6QtGUrVcwO75CkgtlvTUJCahgTsfGQdxF0EvG8w053a3+r2Xz3B2DxZ9F cjcbaZLQnkIYXzuRCqjRtM9eDIRMPWLLmt8EVkBU4QbLK9UDoGPt77D+ie0Bx6NSa2qeavZKHXrB8w== X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-01-16 08:18, Corinna Vinschen via Cygwin wrote: > Hi Takashi, > > On Jan 16 23:45, Takashi Yano via Cygwin wrote: >> On Mon, 16 Jan 2023 11:23:54 +0100 >> Corinna Vinschen wrote: >>> On Jan 16 18:02, Takashi Yano via Cygwin wrote: >>> [...] >>>> Errors seem to be three types: (null), cygpid.xxx and shared.5. >>>> I'm not sure what is happening and why at all, however, this >>>> did not seem to happen before the commit 30add3e6b3e3. >>> >>> I'll try to reproduce this issue. But the weird thing is certainly >>> this: The affected shared mem regions are apparently not the cygheap. >>> Rather, they are the "shared" and "cygpid" shared mem regions, which >>> should not at all collide with the cygheap. I guess we need more >>> debug output in the api_fatal call inside open_shared... >> >> I am now trying the test case with reverting the commit 60675f1a7eb2 >> "Cygwin: decouple shared mem regions from Cygwin DLL", and the issue >> does not happen for several hours so far. I guess this most likely >> is the direct cause of the problem. > > Actually, I' running your testcase on two machines in parallel now for > quite some time, which only one hunk of 60675f1a7eb2 reverted, i.e. > > diff --git a/winsup/cygwin/mm/shared.cc b/winsup/cygwin/mm/shared.cc > index 893b20d289b4..6d6d2940b6d4 100644 > --- a/winsup/cygwin/mm/shared.cc > +++ b/winsup/cygwin/mm/shared.cc > @@ -140,7 +140,11 @@ open_shared (const WCHAR *name, int n, HANDLE& shared_h, DWORD size, > if (*m == SH_JUSTCREATE || *m == SH_JUSTOPEN) > addr = NULL; > else > - addr = (void *) region_address[*m]; > + { > + addr = (void *) region_address[*m]; > + VirtualFree (addr, 0, MEM_RELEASE); > + } > + > > WCHAR map_buf[MAX_PATH]; > WCHAR *mapname = NULL; > > So far (and knocking on wood madly while writing this) the mapping > problem didn't show up once. Maybe you'd like to try the same? After struggling to build and release a new ncurses test package yesterday, with many hangs including unrelated hourly cron jobs, make, top, ps, and using Cygwin /bin/ps and /bin/kill -f combos a lot to make progress, I upgraded last night to latest including *cygwin test 3.5.0-0.107.g8bd56ec87345*, and an ncurses rebuild, and another package rebuild, with top monitoring under X and usual hourly cron jobs running had no issues for the first time in weeks! I also have a couple of cygcheck -cd cygwin loops running, and damn, *just* got a failure on one, and stackdump is zero length: $ 0 [main] cygcheck (16228) C:\usr\local\cygwin64\bin\cygcheck.exe: *** fatal error - MapViewOfFileEx '(null)'(0x108), Win32 error 487. Terminating. 1260 [main] cygcheck (16228) cygwin_exception::open_stackdumpfile: Dumping stack trace to cygcheck.exe.stackdump $ ls -glo *.stackdump -rwxr-xr-x 1 0 Jan 16 12:16 cygcheck.exe.stackdump -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry