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
