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>
Content-Language: en-US
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
Precedence: list
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>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
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