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.3.2 sourceware.org AA1E6386F425 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=shaddybaddah.name Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=lithium-cygwin AT shaddybaddah DOT name X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduhedrkedtgdduhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvffttedpqfgfvfenuceurghilhhouhhtmecugedttdenucenucfjughrpefuhffvfhfkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefuhhgrugguhicuuegruggurghhuceolhhithhhihhumhdqtgihghifihhnsehshhgrugguhigsrgguuggrhhdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeektefhteehteelteehvdevudduueefheejheevudevueejtdevleegffdtgeefgeenucfkphepvddtfedrgedtrdduieekrddvhedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgdtrddtrddtrddtngdpihhnvghtpedvtdefrdegtddrudeikedrvdehvddpmhgrihhlfhhrohhmpeeolhhithhhihhumhdqtgihghifihhnsehshhgrugguhigsrgguuggrhhdrnhgrmhgvqecuuefqffgjpeekuefkvffokffogfdprhgtphhtthhopeeotgihghifihhnsegthihgfihinhdrtghomheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RG-VS-CLASS: clean Subject: Re: Odd hang of cc1.exe *resolved. /tmp/cygwin1.dll. Apologies * cpp/gcc From: Shaddy Baddah To: cygwin AT cygwin DOT com References: <514e1a5d-7173-c6f0-a205-d8f207befc06 AT shaddybaddah DOT name> <9e450e76-6bc8-407a-89d4-edcc934edc5a AT shaddybaddah DOT name> <0dc18394-6194-118a-d3f1-3055c51a352f AT cs DOT umass DOT edu> <7e298112-c64f-4251-ac7f-ccb6cdc2088d AT shaddybaddah DOT name> <7b4feea3-8294-de15-1fdf-0a7095b69d75 AT shaddybaddah DOT name> Message-ID: <78b5c27c-57de-1941-20b7-a9c61e2ec4a8@shaddybaddah.name> Date: Thu, 7 May 2020 19:34:36 +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: <7b4feea3-8294-de15-1fdf-0a7095b69d75@shaddybaddah.name> Content-Language: en-US X-Spam-Status: No, score=-9.4 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: cygwin-bounces AT cygwin DOT com Sender: "Cygwin" Hi, On 7/5/20 1:44 pm, Shaddy Baddah wrote: > 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. I apologise if I've wasted anyone's time on this. I tried resetting the permissions on /tmp, and then on a hunch that some file in /tmp might be inducing the *alleged* (frivolously on my part) issue with Windows, I started removing files one by one. Eventually I noticed a copy of an old cygwin1.dll (actually a custom build of 2.10.0) and that of course was the culprit. And it makes sense now of course. /usr/bin/as (and cc1) are going to load cygwin1.dll in /usr/bin, which is consistent with bash/mintty etc, because it exists in the same directory as the executable. And of course, /tmp/cygwin1.dll was loaded as it was in the current directory, and the executable not being in /usr/bin meant that Windows wasn't using the colocated DLL as the first search result. I'm really sorry Cygwin community. I'll store this one in my memory banks, and hope there is no next time. -- Embarrassedly yours, Shaddy -- 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