Odd hang of cc1.exe, when invoking cpp/gcc

Odd hang of cc1.exe, when invoking cpp/gcc

[Shaddy Baddah]

Hi,

First, I want to acknowledge that this could be exclusively a problem
with my Windows 10 desktop.

The problem I am having is when I run a simple gcc command, say gcc
hello.c, the command hangs.

In mintty, ctrl-c won't kill it. And I have to carefully kill the gcc
process taskmgr, then kill the child cc1 process, before returning to
mintty. Otherwise mintty freezes up and I have to manually kill it
too. From console, ctrl-c just works.

This is happening on my Windows 10 desktop that is a corporate build
of Windows. It is the subject of forced updates, lots of BLODA
potential agents, and weird policies.

It doesn't happen on my personal Windows 10 desktop, so I acknowledge
that this will prejudice this attempt for assistance.

But in the hope that there might be a clue as to why this is
happening, I'll expand a bit further. gcc was working fine as recently
as two months ago. Of course there have been Windows updates, and
Cygwin updates performed since. But as I don't use gcc daily, I don't
know which of these might have broke it.

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.

So if I do strace -f gcc hello.c, these are the dwindling lines of
output from strace:

   184 6193312 [main] gcc 730 child_info::child_info: subproc_ready 0x2F4
537090 6730402 [main] gcc 730 child_info_spawn::worker: pid 731, 
prog_arg /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/cc1.exe, cmd line (null))
  1646 6732048 [main] gcc 730 open_shared: name cygpid.731, n 731, 
shared 0x160000 (wanted 0x0), h 0x31C, *m 5
   269 6732317 [main] gcc 730 time: 1587970202 = time(0x0)
   301 6732618 [main] gcc 730 proc_subproc: args: 1, -25504
   378 6732996 [main] gcc 730 proc_subproc: returning 1
  1984 6734980 [main] gcc 730 proc_subproc: args: 2, -25504
  4374 6739354 [main] gcc 730 pinfo::wait: created tracking thread for 
pid 731, winpid 0x1668, rd_proc_pipe 0x2FC
   478 6739832 [main] gcc 730 proc_subproc: added pid 731 to proc table, 
slot 0
   355 6740187 [main] gcc 730 proc_subproc: returning 1
  3219 6743406 [main] gcc 730 child_info_spawn::worker: spawned windows 
pid 5736
  2144 6745550 [main] gcc 730 child_info::sync: n 2, waiting for 
subproc_ready(0x2F4) and child process(0x308) --- Process 2784 (pid: 
730) thread 15060 created
--- Process 2784 (pid: 730) thread 19632 created

After a little while, I see staggered (and continuing) lines like:

--- Process 2784 (pid: 730) thread 17992 exited with status 0x0
--- Process 2784 (pid: 730) thread 2624 exited with status 0x0
--- Process 2784 (pid: 730) thread 18504 exited with status 0x0

Any ideas?

-- 
Regards,
Shaddy

Re: Odd hang of cc1.exe *now isolated somewhat* cpp/gcc

[Shaddy Baddah]

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
% <hang until ctrl-c>

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

Re: Odd hang of cc1.exe *now isolated somewhat* cpp/gcc

[Eliot Moss]

Could it be a cygwin fork problem?  Definitely possible
in a 32-bit environment.  I had to rebase all the time.
Now that I'm mostly in the 64-bit environment it's not
such an issue.

Regards - Eliot Moss

Re: Odd hang of cc1.exe *now further isolated, potential console issues* cpp/gcc

[Shaddy Baddah]

Hi Eliot,

On 28/4/20 10:46 pm, Eliot Moss wrote:
> Could it be a cygwin fork problem?  Definitely possible
> in a 32-bit environment.  I had to rebase all the time.
> Now that I'm mostly in the 64-bit environment it's not
> such an issue.

I suspected so and did trigger a rebaseall... it hasn't helped.
As mysterious as this problem is, I can't rule out fork issues, but I
have new information that suggests it might be something odd with
console/pty I/O???

So, if I run cc1 from bash, under a command prompt window, it will
will seemingly hang. However if I enter ctrl-d, the command resumes
and seems to run (I can't say if correct or not).

Here's what I mean:

| $ /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
<nothing happens>
<enter ctrl-d>
|
| Analyzing compilation unit
| Performing interprocedural optimizations
|  <*free_lang_data> <visibility> <build_ssa_passes> <opt_local_passes> 
<remove_symbols> <targetclone> <free-fnsummary> <emutls>Streaming LTO
|  <whole-program> <fnsummary> <inline> <free-fnsummary> 
<single-use>Assembling functions:
|  <materialize-all-clones> <simdclone>
| Time variable                                   usr           sys 
     wall               GGC
|  phase setup                        :   0.01 (100%)   0.00 (  0%) 
0.01 ( 40%)    1224 kB ( 90%)
|  phase opt and generate             :   0.00 (  0%)   0.00 (  0%) 
0.01 ( 28%)       2 kB (  0%)
|  TOTAL                              :   0.01          0.00 
0.03           1357 kB
|
| $

If I try this in mintty, the ctrl-d isn't accepted, and the hard hang
continues. ctrl-c doesn't work, and I have to resort to killing
processes in taskmgr (haven't tried just using Cygwin kill. Can if it
makes a difference).

So, it seems like even though cc1 is probably not reading the console,
Windows things it needs events from that source for some reason??? It's
all a bit above my pay grade at the moment.

Also, for completeness, I went back to Cygwin DLL 3.0.6-1, and the
problem persisted. Mind you, until recent modifications to the desktop
(Windows updates, and whatever other agents pushed by corporate IT)
gcc/cc1 was working with 3.1 series DLLs... go figure :-(

Any ideas?

-- 
Regards,
Shaddy

Re: Odd hang of cc1.exe *now further isolated, potential console issues* cpp/gcc

[Marco Atzeri]

Am 29.04.2020 um 06:06 schrieb Shaddy Baddah:
> Hi Eliot,
> 
> On 28/4/20 10:46 pm, Eliot Moss wrote:
>> Could it be a cygwin fork problem?  Definitely possible
>> in a 32-bit environment.  I had to rebase all the time.
>> Now that I'm mostly in the 64-bit environment it's not
>> such an issue.
> 
> I suspected so and did trigger a rebaseall... it hasn't helped.
> As mysterious as this problem is, I can't rule out fork issues, but I
> have new information that suggests it might be something odd with
> console/pty I/O???
> 

I bet on some BLODA interfering on execution and creating a
time glitch.

Unfortunately is not new. Can you teach you AV to avoid the
cygwin directories ?

Marco

Re: Odd hang of cc1.exe *now further isolated, back to a fork issue* cpp/gcc

[Shaddy Baddah]

Hi,

On 29/4/20 2:06 pm, Shaddy Baddah wrote:
> Hi Eliot,
> 
> On 28/4/20 10:46 pm, Eliot Moss wrote:
>> Could it be a cygwin fork problem?  Definitely possible
>> in a 32-bit environment.  I had to rebase all the time.
>> Now that I'm mostly in the 64-bit environment it's not
>> such an issue.
> 
> I suspected so and did trigger a rebaseall... it hasn't helped.
> As mysterious as this problem is, I can't rule out fork issues, but I
> have new information that suggests it might be something odd with
> console/pty I/O???

OK. I'm back to a fork issue. It has to be. This is the ps output whilst
cc1 is hung in another bash session:

$ ps -ef
      UID     PID    PPID  TTY        STIME COMMAND
  sbaddah     589       1 cons1    19:16:50 /usr/bin/bash
  sbaddah     600     576 cons0    19:17:09 /usr/bin/ps
  sbaddah     576       1 cons0    19:15:58 /usr/bin/bash

cc1 doesn't show, but it is a running Windows process.



> So, if I run cc1 from bash, under a command prompt window, it will
> will seemingly hang. However if I enter ctrl-d, the command resumes
> and seems to run (I can't say if correct or not).
> 
> Here's what I mean:
> 
> | $ /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
> <nothing happens>
> <enter ctrl-d>
> |
> | Analyzing compilation unit<snip/>

So this is interesting. If I run this on the working 32-bit install, it
confirms what I would expect, which is parsed contents of hello.c. The
following output is the equivalent output of not having given *any*
command line options.

So, here's the 32-bit output if I comment out all options but -E:

| $ /usr/lib/gcc/i686-pc-cygwin/9.3.0/cc1.exe -E # -quiet -v -idirafter 
/usr/lib/gcc/i686-pc-cygwin/9.3.0/../../../../include/w32api -idirafter 
/usr/lib/gcc/i686-pc-cygwin/9.3.0/../../../../i686-pc-cygwin/lib/../../include/w32api 
hello.c -mtune=generic -march=i686
| # 1 "<stdin>"
| # 1 "<built-in>"
| # 1 "<command-line>"
| # 1 "<stdin>"
|
| Time variable                                   usr           sys 
     wall               GGC
|  TOTAL                              :   0.00          0.00 
0.72             88 kB

but with even the -E commented:

| $ /usr/lib/gcc/i686-pc-cygwin/9.3.0/cc1.exe # -E -quiet -v -idirafter 
/usr/lib/gcc/i686-pc-cygwin/9.3.0/../../../../include/w32api -idirafter 
/usr/lib/gcc/i686-pc-cygwin/9.3.0/../../../../i686-pc-cygwin/lib/../../include/w32api 
hello.c -mtune=generic -march=i686
|
| Analyzing compilation unit
| Performing interprocedural optimizations
|  <*free_lang_data> <visibility> <build_ssa_passes> <opt_local_passes> 
<remove_symbols> <targetclone> <free-fnsummary> <emutls>Streaming LTO
|  <whole-program> <fnsummary> <inline> <free-fnsummary> 
<single-use>Assembling functions:
|  <materialize-all-clones> <simdclone>
| Time variable                                   usr           sys 
     wall               GGC
|  phase setup                        :   0.00 (  0%)   0.02 (100%) 
0.02 (  4%)     577 kB ( 88%)
|  TOTAL                              :   0.00          0.02 
0.48            655 kB

Matches what I see when I ctrl-d the *hung* 64-bit cc1.

At this point, I am going to back right off. I am fairly sure now this
is some form of BLODA. We do have something installed that logs all
commands run. And that is so sacred to our IT security team, I've
watched iterations of *hardening* of it, and the service can't be
stopped or the process killed as a Local admin.

Perhaps this is intercepting the process arguments and failing to
*proxy* them when it has recorded them.

I've requested our IT security team assist. I'll workaround this for the
moment. It's very unsettling when your foundations are constantly
shifting.

-- 
Regards,
Shaddy

Re: Odd hang of cc1.exe *now isolated to /tmp weirdness* cpp/gcc

[Shaddy Baddah]

Hi,


On 29/4/20 10:38 pm, Shaddy Baddah wrote:
> Matches what I see when I ctrl-d the *hung* 64-bit cc1.
> 
> At this point, I am going to back right off. I am fairly sure now this
> is some form of BLODA. We do have something installed that logs all
> commands run. And that is so sacred to our IT security team, I've
> watched iterations of *hardening* of it, and the service can't be
> stopped or the process killed as a Local admin.
> 
> Perhaps this is intercepting the process arguments and failing to
> *proxy* them when it has recorded them.
> 
> I've requested our IT security team assist. I'll workaround this for the
> moment. It's very unsettling when your foundations are constantly
> shifting.


As I expected, I given very short shrift from the IT security
team. Not to worry. I tried a number of things, including running
Windows in safe mode, where seemingly these potential BLODA agents
aren't running. Nothing helped. Until...

I have to come to discover, it is not just cc1 being affected, it is
at least as running out of /usr/x86_64-pc-cygwin/bin that is
affected. And only when run out of my /tmp (which is custom mapped
btw).

Here is the absolutely bizarre and inexplicable example of the issue:

| ~$ /bin/as --help
| Usage: /bin/as [option...] [asmfile...]
| ...
| Report bugs to <http://www.sourceware.org/bugzilla/>
|
| ~$ /usr/x86_64-pc-cygwin/bin/as --help
| Usage: /usr/x86_64-pc-cygwin/bin/as [option...] [asmfile...]
| ...
| Report bugs to <http://www.sourceware.org/bugzilla/>
|
| ~$ cd /tmp
| /tmp$ /bin/as --help
| Usage: /bin/as [option...] [asmfile...]
| ...
| Report bugs to <http://www.sourceware.org/bugzilla/>
|
| /tmp$ /usr/x86_64-pc-cygwin/bin/as --help
| <ctrl-d>
| /tmp$

And just to be clear, as.exe is hardlinked at each path:

| /tmp$ ls -li /usr/bin/as.exe /usr/x86_64-pc-cygwin/bin/as.exe
| 1688849860843563 -rwxr-xr-x 2 AUD-ELIDED+portapps AUD-ELIDED+None 
5981696 Mar 15 15:16 /usr/bin/as.exe
| 1688849860843563 -rwxr-xr-x 2 AUD-ELIDED+portapps AUD-ELIDED+None 
5981696 Mar 15 15:16 /usr/x86_64-pc-cygwin/bin/as.exe

So obviously the /tmp mount must have some trait that is triggering
this. But I must use the word triggering, because I also built a debug
version of cygwin1.dll. And it seems clear to me that the problem is
in the sigproc code, called off of a spawn I believe, specifically
this:

https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/sigproc.cc;h=7286e323815d75f771fba54d7797a3d36273a242;hb=81b34409985ce31415a1d994ef744e72cfb8c378#l1032

1031   sigproc_printf ("n %d, waiting for subproc_ready(%p) and child 
process(%p)", n, w4[0], w4[1]);
1032   DWORD x = WaitForMultipleObjects (n, w4, FALSE, howlong);
1033   x -= WAIT_OBJECT_0;
1034   if (x >= n)
1035     {

For whatever reason, WaitForMultipleObjects() blocks within Cygwin
dll. The windows process is running, but obviously, the Cygwin process
is not fully formed (as I understand it, the pid is registered after
this call returns). ps doesn't show it.

Further, if I enter ctrl-d, WaitForMultipleObjects() returns, but as
per my earlier emails, behaves as if I had not given any arguments
(just like cc1 from my earlier emails).

At this point, it seems it has to be a Windows bug. It also could be a
way of calling WaitForMultipleObjects() which has worked in 99.9% of
cases, but based off of this article, needs some form of precheck
code:

https://groups.google.com/forum/#!topic/comp.programming.threads/3qtP79SkU64


| comp.programming.threads ›
| WaitForMultipleObjects never wakes up - Windows-bug?
...
| Bonita Montero	
| 5/23/16
| I've got a solution for this problem.
| In the main-thread, simply wait for the semaphore and then for the
| event (in this order - or you're gonna deadlock) with WaitForSingle
| Object. That's not so efficitent, but works.


I don't understand the existing code well enough to know if this the
article is as relevant that it appears, at face value.

In any case, at least I have my solution for the moment. Avoid the
crutch of dumping a simple C program in /tmp and compiling. It is
going to end in tears.

--
Regards,
Shaddy

Re: Odd hang of cc1.exe *now isolated to /tmp weirdness* cpp/gcc

[Doug Henderson]

On Wed, 6 May 2020 at 08:34, Shaddy Baddah <> wrote:

> On 29/4/20 10:38 pm, Shaddy Baddah wrote:
>


> <snip>
>
> … And only when run out of my /tmp (which is custom mapped btw).
>
> <snip>
>


> | /tmp$ ls -li /usr/bin/as.exe /usr/x86_64-pc-cygwin/bin/as.exe
> | 1688849860843563 -rwxr-xr-x 2 AUD-ELIDED+portapps AUD-ELIDED+None
> 5981696 Mar 15 15:16 /usr/bin/as.exe
> | 1688849860843563 -rwxr-xr-x 2 AUD-ELIDED+portapps AUD-ELIDED+None
> 5981696 Mar 15 15:16 /usr/x86_64-pc-cygwin/bin/as.exe
>


> <snip>
>

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.

HTH,
Doug

-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com

Re: Odd hang of cc1.exe *now isolated to /tmp weirdness* cpp/gcc

[Shaddy Baddah]

Hi Doug,

On 7/5/20 11:19 am, Doug Henderson via Cygwin wrote:
> <snip> 
> 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

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

[Shaddy Baddah]

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