DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 4AKDiCgc3637163 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 4AKDiCgc3637163 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=rfx/TjbU X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C83B03858416 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1732110250; bh=Y0EAfEgURseHmSNKsLHVs48mYqRD+vAckrJ5hpTNr7I=; 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=rfx/TjbUI9Xy8Y6pA70XElpTBEEQD2siB1idml0vMKL4VEHUs2KPY/VpMCTOTRaHW AhiFZDe+WE0JMt+c8q90YWqLR9lMCKBvT/+9uPiFIptNIvd5KJ3lCHiLvAbb2DmJp0 mrcTbuQMCbvhVGC0YIYA8HJh/vDrGiLqDrDPVSb0= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7529D3858D38 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7529D3858D38 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1732110192; cv=none; b=WuImhvxaf6C0Ph1PiAZvFhiKVa8w1CfrhS/W4A/Y2n/4sDsnau8kPMKa2HkSoMf8B1Va4goJpnYISExyPaprUiXybLH8GSP8y+JqbFbzxwrwefJk6CJjCFcGhKyl70RXT1iKS+NodQeysxiPKG4crMB84dSY7dVt5hrA7NUq/UA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1732110192; c=relaxed/simple; bh=RZ5p9djceQKhg9C78Bjx7q56M7fo4pYZkmyHa0CEGs8=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=ExRXEih/8s7KLJuhlRUqDWB5S0GHXnYZxFBpZ8OpAIv2ssuL366/dnT/InCp1sKha/sLuQbeFPr6P/7IqdKFtp2ZCsxtztMWBvi42Y9aJM6evE8+FWbUrB3LtYGlZucrpAv0uX6VCXT49NBjN817xNuaGvBhRsmfRmJb9EoUkzg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7529D3858D38 Date: Wed, 20 Nov 2024 22:43:08 +0900 To: cygwin AT cygwin DOT com Subject: Re: SIGKILL may no longer work after many SIGCONT/SIGSTOP signals Message-Id: <20241120224308.000a18e48c0b8926e82e5147@nifty.ne.jp> In-Reply-To: <20241119182152.c2195f50ed7091fbed644606@nifty.ne.jp> References: <20241119182152 DOT c2195f50ed7091fbed644606 AT nifty DOT ne DOT jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 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 Tue, 19 Nov 2024 18:21:52 +0900 Takashi Yano wrote: > On Tue, 12 Nov 2024 10:53:58 +0100 > Christian Franke wrote: > > Found with 'stress-ng --cpu-sched' from current stress-ng upstream HEAD: > > > > Testcase (attached): > > > > $ gcc -O2 -o manysignals manysignals.c > > > > $ ./manysignals > > fork() = 1833 > > ... > > fork() = 1848 > > ... > > kill(1833, 17) > > ... > > kill(1848, 17) > > kill(1833, 9) > > ... > > kill(1848, 9) > > waitpid(1833, ., 0) > > > > > > Run this in second terminal: > > > > $ watch "ps | sed -n '1p;/manysignals/{/sed/d;p}'" > > > > If 'S' appear in the first column, the child processes likely reached > > the final SIGSTOP state. This takes some time. The parent process may > > still hang in first waitpid() but should not. > > > > If the parent process is aborted with ^C, child processes may be stopped > > or left behind. Occasionally a child process that can not be stopped by > > Cygwin (kill -9) is left behind. > > > > Tested with ancient (i7-2600K) and more recent (i7-14700K) CPU :-) > > > > > > Unrelated to the above, but related to 'stress-ng --cpu-sched' which > > uses sched_get/setscheduler(): > > > > - sched_getscheduler() always returns SCHED_FIFO. As far as I understand > > Linux sched(7), this is a non-preemptive real-time policy. The > > preemptive SCHED_RR would possibly a more reasonable value. > > Unfortunately SCHED_OTHER cannot be used because it would require to > > ignore the priority. > > > > - sched_setscheduler() always fails with ENOSYS. It IMO should allow to > > set 'param->sched_priority' if 'policy' is equal to the value returned > > by sched_getscheduler(). > > Thanks for the report and the test case. I'm now looking into > the issue. Please wait a while. Hopefully, I have found the cause. The deadlock happens between main thread and wait_sig thread. The main thread is waiting for the wait_sig thread triggering wakeup event while the wait_sig thread is waiting previous signal being processed by main thread. Let me consider how to fix that. -- 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