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 D57E0386F465
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:	gggruggvucftvghtrhhoucdtuddrgeduhedrjeekgdejfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvffttedpqfgfvfenuceurghilhhouhhtmecugedttdenucgoufhushhpvggtthffohhmrghinhculdegledmnecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepufhhrgguugihuceurgguuggrhhcuoehlihhthhhiuhhmqdgthihgfihinhesshhhrgguugihsggruggurghhrdhnrghmvgeqnecuggftrfgrthhtvghrnhepheefkefhteduvefgudegvdeuvdevvddugefgleffleehudeitefgiedvleejgedvnecuffhomhgrihhnpehsohhurhgtvgifrghrvgdrohhrghdptgihghifihhnrdgtohhmpdhgohhoghhlvgdrtghomhenucfkphepvddtfedrgedtrdduieekrddvhedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgdtrddtrddtrddtngdpihhnvghtpedvtdefrdegtddrudeikedrvdehvddpmhgrihhlfhhrohhmpeeolhhithhhihhumhdqtgihghifihhnsehshhgrugguhigsrgguuggrhhdrnhgrmhgvqecuuefqffgjpeekuefkvffokffogfdprhgtphhtthhopeeotgihghifihhnsegthihgfihinhdrtghomheq
X-RazorGate-Vade-Verdict:	clean 49
X-RazorGate-Vade-Classification:	clean
X-RG-VS-CLASS:	clean
Subject:	Re: Odd hang of cc1.exe *now isolated to /tmp weirdness* 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>
	<bb40bbcc-a0c5-7708-f739-d102bd75a91a AT shaddybaddah DOT name>
From:	Shaddy Baddah <lithium-cygwin AT shaddybaddah DOT name>
Message-ID:	<7e298112-c64f-4251-ac7f-ccb6cdc2088d@shaddybaddah.name>
Date:	Thu, 7 May 2020 00:29:29 +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:	<bb40bbcc-a0c5-7708-f739-d102bd75a91a@shaddybaddah.name>
X-Spam-Status:	No, score=-11.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	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 046EUGYB014821

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

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