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
