Re: Odd hang of cc1.exe *now isolated to /tmp weirdness* cpp/gcc

[Shaddy Baddah <lithium-cygwin@shaddybaddah.name>]

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