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> From: Shaddy Baddah Message-ID: 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: Content-Language: en-US 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 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: cygwin-bounces AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit 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 > > > | > | Analyzing compilation unit 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 "" | # 1 "" | # 1 "" | # 1 "" | | 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> Streaming LTO | Assembling functions: | | 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