Re: Odd hang of cc1.exe *resolved. /tmp/cygwin1.dll. Apologies * cpp/gcc

[Shaddy Baddah <lithium-cygwin@shaddybaddah.name>]

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