From: Shaddy Baddah <lithium-cygwin@shaddybaddah.name>
To: cygwin@cygwin.com
Subject: Re: Odd hang of cc1.exe *now further isolated, back to a fork issue* cpp/gcc
Date: Wed, 29 Apr 2020 22:38:56 +1000 [thread overview]
Message-ID: <bb40bbcc-a0c5-7708-f739-d102bd75a91a@shaddybaddah.name> (raw)
In-Reply-To: <ccd57ee7-2679-45b4-c11d-73bd85a99744@shaddybaddah.name>
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
next prev parent reply other threads:[~2020-04-29 12:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-27 6:54 Odd hang of cc1.exe, when invoking cpp/gcc Shaddy Baddah
2020-04-28 5:23 ` Odd hang of cc1.exe *now isolated somewhat* cpp/gcc Shaddy Baddah
2020-04-28 12:46 ` Eliot Moss
2020-04-29 4:06 ` Odd hang of cc1.exe *now further isolated, potential console issues* cpp/gcc Shaddy Baddah
2020-04-29 4:55 ` Marco Atzeri
2020-04-29 12:38 ` Shaddy Baddah [this message]
2020-05-06 14:29 ` Odd hang of cc1.exe *now isolated to /tmp weirdness* cpp/gcc Shaddy Baddah
2020-05-07 1:19 ` Doug Henderson
2020-05-07 3:44 ` Shaddy Baddah
2020-05-07 9:34 ` Odd hang of cc1.exe *resolved. /tmp/cygwin1.dll. Apologies * cpp/gcc Shaddy Baddah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb40bbcc-a0c5-7708-f739-d102bd75a91a@shaddybaddah.name \
--to=lithium-cygwin@shaddybaddah.name \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).