X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org 426C138930CB
Authentication-Results:	sourceware.org; dmarc=none (p=none dis=none)
	header.from=shaddybaddah.name
Authentication-Results:	sourceware.org; spf=fail
	smtp.mailfrom=lithium-cygwin AT shaddybaddah DOT name
X-RG-Spam:	Unknown
X-RazorGate-Vade:	gggruggvucftvghtrhhoucdtuddrgeduhedrieefgdehgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvffttedpqfgfvfenuceurghilhhouhhtmecugedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefuhhgrugguhicuuegruggurghhuceolhhithhhihhumhdqtgihghifihhnsehshhgrugguhigsrgguuggrhhdrnhgrmhgvqeenucfkphepvddtfedrgedtrdduieekrddvhedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgdtrddtrddtrddtngdpihhnvghtpedvtdefrdegtddrudeikedrvdehvddpmhgrihhlfhhrohhmpeeolhhithhhihhumhdqtgihghifihhnsehshhgrugguhigsrgguuggrhhdrnhgrmhgvqecuuefqffgjpeekuefkvffokffogfdprhgtphhtthhopeeotgihghifihhnsegthihgfihinhdrtghomheq
X-RazorGate-Vade-Verdict:	clean 0
X-RazorGate-Vade-Classification:	clean
X-RG-VS-CLASS:	clean
Subject:	Re: Odd hang of cc1.exe *now further isolated, back to a fork issue*
	cpp/gcc
To:	cygwin AT cygwin DOT com
References:	<514e1a5d-7173-c6f0-a205-d8f207befc06 AT shaddybaddah DOT name>
	<9e450e76-6bc8-407a-89d4-edcc934edc5a AT shaddybaddah DOT name>
	<0dc18394-6194-118a-d3f1-3055c51a352f AT cs DOT umass DOT edu>
	<ccd57ee7-2679-45b4-c11d-73bd85a99744 AT shaddybaddah DOT name>
From:	Shaddy Baddah <lithium-cygwin AT shaddybaddah DOT name>
Message-ID:	<bb40bbcc-a0c5-7708-f739-d102bd75a91a@shaddybaddah.name>
Date:	Wed, 29 Apr 2020 22:38:56 +1000
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
	Thunderbird/68.7.0
MIME-Version:	1.0
In-Reply-To:	<ccd57ee7-2679-45b4-c11d-73bd85a99744@shaddybaddah.name>
X-Spam-Status:	No, score=0.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	RCVD_IN_ABUSEAT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_SOFTFAIL,
	TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version:	SpamAssassin 3.4.2 (2018-09-13) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<http://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<http://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 03TCdZKh020492

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

- Raw text -