DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52782VX9875081
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 52782VX9875081
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=fqD9BYur
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 16C6A3858C2C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1741334551;
	bh=8Qkj3eE/DW97C+P/owxAJnK6rhyf0XAg2jsUuNIVaTg=;
	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=fqD9BYurx+zi3nRK59G9r93A+xhylbeh5KSa7tX929xVsuiYudCGcYdhfB5dtnfFz
	 i71kuRU1L/a+K3IKsMzZMwjbIj7nryddk7I4oYp2bqEuH0K80oJX/+wg43m7xFRcz9
	 0miR94hXTz72pKgd8C06mSHwQYKGiHLawILD5nVo=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5853F3858D26
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5853F3858D26
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741334521; cv=none;
 b=LMdx3TkrBnNRQXSvPKLygYEOVJtlXgX3tJxyLF98Zt0j/9rn9iNwB1KNQ1Ccg/eisj4YF9TBtkwyL6LpppW/zNXE6fEjv6RTYjOYo8Uij064KtAqqPm1nDVVyCD6UYJWupW9EovbB94yrAsadIfC6dFGgrm/MRasXf3PzkoPADg=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1741334521; c=relaxed/simple;
 bh=mIMJr8u9SHKSyy7mkJU70Ivv0d5E6MaRsoVGXp6i12Q=;
 h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature;
 b=MP05H0U9xsKGgVHjLC/xSTXcsUVuMvX65fzXBpuAQHbSpS4aSpejQvCoe8UgWTnEI6iOtsBxce7SQI+UsTstkWSJqyXkzlp+EKqiE4Eb8pVXBxaMyVmjuoj5bMSsYY/UcogTNKBBQm/Fs4i/Z57Bc44oFRqUOsgFsbnvXoGEbMU=
ARC-Authentication-Results: i=1; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5853F3858D26
Date: Fri, 7 Mar 2025 17:01:57 +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: <20250307170157.862a6639be4e348b5b10fe83@nifty.ne.jp>
In-Reply-To: <20250307162951.f6d301ec44a0a51fdf32aaf3@nifty.ne.jp>
References: <8c465025-4858-3113-fe2d-ce00dad21f8a AT t-online DOT de>
 <20250228212020 DOT 433a339f073060f65a0a736d AT nifty DOT ne DOT jp>
 <de045db2-09b1-b2ab-d0d6-32f8c6906386 AT t-online DOT de>
 <20250307162951 DOT f6d301ec44a0a51fdf32aaf3 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 <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Takashi Yano via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 52782VX9875081

On Fri, 7 Mar 2025 16:29:51 +0900
Takashi Yano wrote:
> 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.

BTW, the resut of your testcase in Linux is as follows:

231873: fork()=231874
SIGALRM x 10
[ALRM]
[ALRM]
[ALRM]
SIGSTOP
SIGTERM
SIGCONT
waitpid()...
[TERM]
231874: 3 SIGALRM received, exit(42)
waidpid()=231874, status=0x2a00

Signal-lost also happens. However, it does not hang in Linux.
So I guess SIGSTOP/SIGCONT are never lost in Linux.

-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>

-- 
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