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