From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nsstlmta35p.bpe.bigpond.com (nsstlmta35p.bpe.bigpond.com [203.38.21.35]) by sourceware.org (Postfix) with ESMTPS id F01E2383F840 for ; Thu, 7 May 2020 03:44:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F01E2383F840 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 nsstlfep35p-svc.bpe.nexus.telstra.com.au with ESMTP id <20200507034415.DWAX7495.nsstlfep35p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com> for ; Thu, 7 May 2020 13:44:15 +1000 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduhedrjeelgdejvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvffttedpqfgfvfenuceurghilhhouhhtmecugedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefuhhgrugguhicuuegruggurghhuceolhhithhhihhumhdqtgihghifihhnsehshhgrugguhigsrgguuggrhhdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeevjeehjedvgeehgfeludevgeelteevffffheffueekleeuheeutdduleeiieehkeenucfkphepvddtfedrgedtrdduieekrddvhedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgdtrddtrddtrddtngdpihhnvghtpedvtdefrdegtddrudeikedrvdehvddpmhgrihhlfhhrohhmpeeolhhithhhihhumhdqtgihghifihhnsehshhgrugguhigsrgguuggrhhdrnhgrmhgvqecuuefqffgjpeekuefkvffokffogfdprhgtphhtthhopeeotgihghifihhnsegthihgfihinhdrtghomheq 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 5EA7326203FF09CB for cygwin@cygwin.com; Thu, 7 May 2020 13:44:15 +1000 Subject: Re: Odd hang of cc1.exe *now isolated to /tmp weirdness* cpp/gcc To: cygwin@cygwin.com References: <514e1a5d-7173-c6f0-a205-d8f207befc06@shaddybaddah.name> <9e450e76-6bc8-407a-89d4-edcc934edc5a@shaddybaddah.name> <0dc18394-6194-118a-d3f1-3055c51a352f@cs.umass.edu> <7e298112-c64f-4251-ac7f-ccb6cdc2088d@shaddybaddah.name> From: Shaddy Baddah Message-ID: <7b4feea3-8294-de15-1fdf-0a7095b69d75@shaddybaddah.name> Date: Thu, 7 May 2020 13:44:12 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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: Thu, 07 May 2020 03:44:20 -0000 Hi Doug, On 7/5/20 11:19 am, Doug Henderson via Cygwin wrote: > > I think this is the essence of your problem. It looks like you are mapping > you temporary directory outside the cygwin directory tree, Not sure how you > are doing it. For me, I have TMP=/tmp and TEMP=/tmp in my cygwin > environment. In my windows environment, i.e, when running cmd.exe, TEMP and > TMP point to C:\Users\Doug\AppData\Local\Temp. > > I expect you will find that the windows permissions for your temp directory > is different from the default /tmp. > > Check this using lsacl (A bash script found somewhere in this mailing > list.) Or the file properties from windows explorer. > > In my case: > > $ ls -ld /tmp > drwxrwxrwt+ 1 Admin None 0 May 6 18:51 /tmp/ > > $ ls -ld $(cygpath -u 'C:\Users\Doug\AppData\Local\Temp' ) > drwxrwx---+ 1 Doug SYSTEM 0 May 6 18:50 > /cygdrive/c/Users/Doug/AppData/Local/Temp/ > > $ lsacl /tmp > [u::rwx,g::rwx,o::rwx/u::rwx,g::r-x,o::r-x] /tmp > > $ lsacl $(cygpath -u 'C:\Users\Doug\AppData\Local\Temp' ) > [u::rwx,g::rwx,g:Administrators:rwx,m::rwx,o::---/u::rwx,g::rwx,g:SYSTEM:rwx,g:Administrators:rwx,m::rwx,o::---] > /cygdrive/c/Users/Doug/AppData/Local/Temp > > I suggest you change your temporary directory to ./tmp, or align the > permissions. Thanks. Yes, I am mapping my directory outside the cygwin directory tree, via /etc/fstab. I will certainly check the perms and see if they make a difference. However, you must admit, it is weird that running as.exe with path /usr/bin/as.exe does not break like running the same exe with path /usr/x86_64-pc-cygwin/bin/as.exe, out of the same /tmp directory, is inexplicable. And even if perms are involved, it's quite unexpected that spawning a Cygwin executable would behave in a very undesirable way. Whilst I am able to recover the situation with ctrl-d or ctrl-c in a console window (command prompt or ConEmu), under mintty, I get a total lock up if I try ctrl-d or ctrl-c. I can only recover my mintty session by avoiding ctrl-d/c and selectively killing processes via taskmgr (I think child of bash first, then the hung /usr/x86_64-pc-cygwin/bin/ process). I'll accept that my experience must be accounted for as an extreme corner case. But I feel satsified that I have documented it here, in case some silent observers have been experiencing like issues, and not reporting them. On the face of it, those users might have thought it was a problem with mintty, which I don't believe it is. And I want to clarify, I don't think Cygwin's DLL code is at fault at all. If my understanding is correct, there are all sorts of code segments in the DLL where an adjustment has to be made because a Windows API function does not behave consistently, or as per its documentation. I suspect this is an unidentified equivalent. -- Regards, Shaddy