From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nsstlmta21p.bpe.bigpond.com (nsstlmta21p.bpe.bigpond.com [203.38.21.21]) by sourceware.org (Postfix) with ESMTPS id 1A0B0385DC00 for ; Tue, 28 Apr 2020 05:23:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1A0B0385DC00 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=shaddybaddah.name Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=lithium-cygwin@shaddybaddah.name Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep21p-svc.bpe.nexus.telstra.com.au with ESMTP id <20200428052350.WMSX6637.nsstlfep21p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com> for ; Tue, 28 Apr 2020 15:23:50 +1000 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduhedriedtgdeludcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvffttedpqfgfvfenuceurghilhhouhhtmecugedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefuhhgrugguhicuuegruggurghhuceolhhithhhihhumhdqtgihghifihhnsehshhgrugguhigsrgguuggrhhdrnhgrmhgvqeenucfkphepvddtfedrgedtrdduieekrddvhedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgdtrddtrddtrddtngdpihhnvghtpedvtdefrdegtddrudeikedrvdehvddpmhgrihhlfhhrohhmpeeolhhithhhihhumhdqtgihghifihhnsehshhgrugguhigsrgguuggrhhdrnhgrmhgvqecuuefqffgjpeekuefkvffokffogfdprhgtphhtthhopeeotgihghifihhnsegthihgfihinhdrtghomheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RG-VS-CLASS: clean Received: from [0.0.0.0] (203.40.168.252) by smtp.telstra.com (5.8.420) id 5E853F7F0A6B185E for cygwin@cygwin.com; Tue, 28 Apr 2020 15:23:50 +1000 Subject: Re: Odd hang of cc1.exe *now isolated somewhat* cpp/gcc To: cygwin@cygwin.com References: <514e1a5d-7173-c6f0-a205-d8f207befc06@shaddybaddah.name> From: Shaddy Baddah Message-ID: <9e450e76-6bc8-407a-89d4-edcc934edc5a@shaddybaddah.name> Date: Tue, 28 Apr 2020 15:23:46 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <514e1a5d-7173-c6f0-a205-d8f207befc06@shaddybaddah.name> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_ABUSEAT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_SOFTFAIL, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 28 Apr 2020 05:23:55 -0000 Hi, On 27/4/20 4:54 pm, Shaddy Baddah wrote: > Further, doing an strace seems to me to be a little revealing. Whilst > I see cc1.exe in taskmgr, I do not see the process in strace. I realise now that I mightn't expect to see the cc1 process by name in the trace. But I have further information that supercedes this. First, I have a 32-bit install alongside the 64-bit, and gcc/cpp/cc1 run fine. I've also isolated the cc1 hang a little. If I run cpp -v hello.c, I obtain the cc1 command-line. Running this directly from a command prompt, cc1 runs fine: % > ..\lib\gcc\x86_64-pc-cygwin\9.3.0\cc1.exe -E -quiet -v -idirafter /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../lib/../include/w32api -idirafter /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api c:\Users\Public\Temp\cygwin64\hello.c -mtune=generic -march=x86-64 ignoring nonexistent directory "/usr/local/include" % ... % } % % > If I run it from bash (or ash), I get the hang: % $ /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/cc1.exe -E -quiet -v -idirafter /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../lib/../include/w32api -idirafter /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api hello.c -mtune=generic -march=x86-64 % However, if I run it under strace, it runs to completion: % $ strace -o cc1.out -f /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/cc1.exe -E -quiet -v -idirafter /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../lib/../include/w32api -idirafter /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api hello.c -mtune=generic -march=x86-64 ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-cygwin/9.3.0/include" % ... % } % % $ I know at this stage, this problem looks even more localised. But by my reckoning, it seems unlikely that this is an issue to do with the various agent processes etc. installed. Because why would running cc1 directly from command prompt not be affected or intercepted? I feel it is more likely to be a side-effect of a recent Windows update. From my previous email, it seems like a hang in WaitForMultipleObjects()... a race-condition of some sort??? By why. Any ideas? Anyone else having gcc issues? -- Regards, Shaddy