From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) by sourceware.org (Postfix) with ESMTPS id 6F3B8385840C for ; Thu, 7 Apr 2022 23:54:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6F3B8385840C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=systematicsw.ab.ca Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id cX8OnfiUp43SgcbxTnd6Lp; Thu, 07 Apr 2022 23:54:35 +0000 Received: from [10.0.0.5] ([184.64.124.72]) by cmsmtp with ESMTP id cbxRnGl52159UcbxSnEwSM; Thu, 07 Apr 2022 23:54:34 +0000 X-Authority-Analysis: v=2.4 cv=frTP2X0f c=1 sm=1 tr=0 ts=624f79ba a=oHm12aVswOWz6TMtn9zYKg==:117 a=oHm12aVswOWz6TMtn9zYKg==:17 a=IkcTkHD0fZMA:10 a=uYT-Tk0qkVT609LjNaIA:9 a=QEXdDO2ut3YA:10 Message-ID: <23e627a3-39a7-e22f-6372-65d50f1a63d6@SystematicSw.ab.ca> Date: Thu, 7 Apr 2022 17:54:33 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Reply-To: cygwin@cygwin.com Subject: Re: Deadlock of the process tree when running make Content-Language: en-CA To: cygwin@cygwin.com References: <9388316255ada0e0fcb2d849cce5a894@ispras.ru> Cc: Alexey Izbyshev From: Brian Inglis Organization: Systematic Software In-Reply-To: <9388316255ada0e0fcb2d849cce5a894@ispras.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfPze1lCqUpLcuAwagiw4QNTtHC4GqYPPWc4XuFW+PAa/OnrLfRCDbam+l1cRM6G3abA+7z8pf3IsZBGRCRc9Moi/73iFg3Ms+eBJgPj/sBi36YgV7JDE CSAynVpG1U91mlGUaUfdsT9RK15EsLNDCJgALweU2RhvdKJ1W1ktzMMgE+/9xeO3cshTgAbyKqTirtk0bMei0pVPbWHwzdU3KycMAQp9226Q60eWmncb4cCs X-Spam-Status: No, score=-1163.9 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.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: , X-List-Received-Date: Thu, 07 Apr 2022 23:54:36 -0000 On 2022-04-07 15:53, Alexey Izbyshev wrote: > I'm using 32-bit Cygwin 3.3.4 on 64-bit Windows 10 21H2. When running > parallel make (for testing my project), very rarely I get the whole > process tree hanging at some seemingly random point. An example of such > a tree: > > make-+-make-+-bash---find >      |      |-bash---find >      |      |-bash---find >      |      |-bash---find >      |      |-bash---find >      |      `-bash---javac >      `-make-+-bash---bash---bash---readlink >             `-bash---bash---bash-+-grep >                                  `-grep > > (In the above tree, javac is the zombie parent of a native javac, and > the latter doesn't exist at this point). > > I got such hang two times while running make in a loop for several days. > ProcessHacker shows that all leaf processes are single-threaded and are > stuck on WaitForSingleObject(). > > I've skimmed git log of cygwin-3_3-branch after cygwin-3_3_4-release, > but couldn't find anything that seems definitely related. > > Has anybody seen something like this? > > Is there any way I can get useful data for diagnosing this hang from the > process tree that I currently have hanging (I'm going to keep it for > now)? Otherwise, what would be the best strategy? I've seen infinite loops with readlink in build scripts under Cygwin. Seeing that readlink in a process tree makes me suspicious that something in a shell script is looping because two paths never match or always match under Cygwin. Often there is one constant path and a varying path which is subjected to readlink in a loop. Under Cygwin, you may have to pass the first path through readlink and compare that resulting path against the varying value. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]