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
--
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
