X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BA01D3858C27 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1673344980; bh=CUkHv1ILz8sowVScf726n1brmO2kL5rwqw3Zhbc+AhU=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=gBYBBcCMxJlwkuVKfXOvWMZEvq4Ck4hXJi0UJRwvEW/zAiDR5o2z976L3QQ/7l8sM gp6kR4MUt6kyii4oy3JuEOF6DSjgN6e+f2veXlSB7/R5Jm3znzr6wESez+215Bf+2U hmm15I35yscOG1G0WjYdYxuieflvfUgHg9GTIbRs= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 886B93858CDA DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-03.nifty.com 30AA1jQs004136 X-Nifty-SrcIP: [220.150.135.41] Date: Tue, 10 Jan 2023 19:01:45 +0900 To: cygwin AT cygwin DOT com Subject: Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/... Message-Id: <20230110190145.ed5438f6c7a9d979899fa823@nifty.ne.jp> In-Reply-To: References: <4a4427cc-422b-1d14-015e-26523e620d9b AT Shaw DOT ca> <20230102113201 DOT 476c10bef7a5643bddc00762 AT nifty DOT ne DOT jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: , From: Takashi Yano via Cygwin Reply-To: Takashi Yano Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" On Mon, 9 Jan 2023 18:13:26 +0100 Corinna Vinschen wrote: > If q->sigtls is NULL, the signal is nevertheless waiting for being > handled. It's just not directed at a specific thread. Beats me, why > this didn't occur in my testing. The process signal info should contain > the process-wide mask of pending signals as well, obviously, so the > following patch should do the right thing: > > diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc > index ce36c8be37fb..86e4e607ab7e 100644 > --- a/winsup/cygwin/sigproc.cc > +++ b/winsup/cygwin/sigproc.cc > @@ -1375,7 +1375,8 @@ wait_sig (VOID *) > *pack.mask = 0; > while ((q = q->next)) > { > - if (q->sigtls->sigmask & (bit = SIGTOMASK (q->si.si_signo))) > + _cygtls *sigtls = q->sigtls ?: _main_tls; > + if (sigtls->sigmask & (bit = SIGTOMASK (q->si.si_signo))) > { > tl_entry = cygheap->find_tls (q->si.si_signo, issig_wait); > if (tl_entry) > > Can you confirm? I confirmed that your patch fixes the issue. This issue can be easily reproduced in my environment by: 1) Open two mintty windows. 2) Run "while true; do procps; done" in one mintty. 3) Build cygwin1.dll in another window. Build hangs in a short time and response of procps slows down. -- Takashi Yano -- 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