DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 5277URE3864780 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 5277URE3864780 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=wy5DjlyJ X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2A2903858C2C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1741332625; bh=sAHaLrwYOBFypqEFACKIU9698SiBiIuR14T2s3XNidw=; 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=wy5DjlyJEmkAeJBWPKLRqqOo3OP6D9PlXP4298RInCSaVmpgYDWnNfWm1Py8t6WaH V7lPCkr6wWkA4logPdFMH3vUu2IYGbvJdDBoeXtYms57J9RpIMhyio3BYoXSNGys0b h6/niTiwvqOhnrClCODM541j3OV8tE2RbrGQDXjc= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E40D73858D1E ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E40D73858D1E ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741332597; cv=none; b=IrlFxxge0JKe5k6VTCnhpTzQDL8i6hxatchSpClF4wyrYIussMfu1wSIXD5IyWypzV5K9C8P1JEFAud3SnMECA45kqgyEaXfu1hrHEQ+m89VY2ydAak6Bb0eV0A8DRHRrehL4q+Ha9bYOIEZnIotVx9B9fpuP9TrLE89iTefIeU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741332597; c=relaxed/simple; bh=+erSyq9zYgSBep9SrOrg5LFn7fhCL2chXASvP9ipVug=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=PEc5X9h32um343hFj7KKbSzUA4J+fZ8ur31LgO9uSsNEmqphrayrjo2vWhiozqJ5qbSCLez83YFGbHKw/cpv2n5S9NNTKd78R50sR+8sn33w919zOqB60SmMJgyPH+qCVDb+dlqESxLAhNMG3+8PqKabCMBD7APyctfjR5O+tmk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E40D73858D1E Date: Fri, 7 Mar 2025 16:29:51 +0900 To: cygwin AT cygwin DOT com Subject: Re: lost signal (was: cygwin 3.6.0: Signals may fail permanently if received after SIGSTOP) Message-Id: <20250307162951.f6d301ec44a0a51fdf32aaf3@nifty.ne.jp> In-Reply-To: References: <8c465025-4858-3113-fe2d-ce00dad21f8a AT t-online DOT de> <20250228212020 DOT 433a339f073060f65a0a736d 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="utf-8" Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 5277URE3864780 On Wed, 5 Mar 2025 11:23:26 +0100 Christian Franke wrote: > Takashi Yano via Cygwin wrote: > > On Mon, 24 Feb 2025 11:29:59 +0100 > > Christian Franke wrote: > >> Found with 'stress-ng --cpu-sched 1': > >> > >> Testcase (attached): > >> > >> $ uname -r > >> 3.6.0-0.387.g8cebbb2b42bf.x86_64 > >> > >> $ gcc -o timersig timersig.c > >> > >> $ ./timersig > >> 638: fork()=639 > >> !!!!!!!!!!!!!...!!!!!!!!!!!!!SIGSTOP: Permission denied > >>     0 [itimer] timersig 639 sig_send: error sending signal 14, pid 639, > >> pipe handle 0x14C, nb 0, packsize 192, Win32 error 0 > >> SIGKILL: Permission denied > >> > >> $ kill 639 > >> -bash: kill: (639) - Permission denied > >> > >> $ kill -9 639 > >> -bash: kill: (639) - Permission denied > >> > >> $ /bin/kill --force 639 > >> > >> $ /bin/kill --force 639 > >> kill: 639: No such process > >> > >> > >> A similar problem, but without the "error sending signal" message, > >> occurs if the timer is not used but the parent process issues SIGSTOP > >> SIGALRM SIGCONT ... sequences. > > Thanks for the report, especially for the test case. I was able to > > easily reproduce the issue. However, I haven't found the cause until > > today. I spent 3 days investigating and discovered three bugs that > > prevent the test case from behaving as expected. > > > > I'll submit the patch seriese shotly. > > Testcase works as expected with 3.6.0-0.419.g3c1308ed890e.x86_64, thanks! > > > Unfortunately signals may be lost, a new testcase is attached: > > $ uname -r > 3.6.0-0.419.g3c1308ed890e.x86_64 > > $ gcc -o lostsig lostsig.c > > $ ./lostsig > 1157: fork()=1158 > SIGALRM x 10 > [ALRM] > [ALRM] > [ALRM] > SIGSTOP > [ALRM] > SIGTERM > SIGCONT > waitpid()... > [TERM] > 1158: 4 SIGALRM received, exit(42) > waidpid()=1158, status=0x2a00 > > $ ./lostsig > 1163: fork()=1164 > SIGALRM x 10 > SIGSTOP > SIGTERM > SIGCONT > waitpid()... > [ALRM] > [TERM] > ...hangs... > > > A 'ps' is a second terminal then shows that the child process is still > in S)topped state. 'kill -CONT ...' works to continue. > > If the testcase is assigned to a single core with 'taskset 0x1 ...', it > apparently always hangs. Thanks for the report and the testcase. The current implementation of the signal queue has the following problems: 1) Signals in the queue are processed in a disordered manner. 2) If the same signal is already in the queue, new signal is discarded. I am working on this issue and almost finished. Now I'm testing. Please wait a while. -- 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