DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 54U8m7Kp1008685
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 54U8m7Kp1008685
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=k3O0pHUE
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 973C03857BA0
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1748594885;
	bh=u6A+SWf/57kr8M1tg3tenPxrQHMDUWTfPjj7sbBoK3U=;
	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=k3O0pHUEBsoTEA9lOi/cQbaoAdZThJkFiCsDyD5VS/aAoxYxN1WpGUsbyOzIAPutv
	TJukGktQ+ijN+1GG/duKJMMUD7u+xJuAG0+wyewXdsCBDKCPYuhv76c5lRSCdpN36q
	nf40rZidifodEedgV/RJQ10Z17pKfzt+1ilDWsXw=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 7DFE7385840D
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 7DFE7385840D
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1748594855; cv=none;
	b=b/dQ4ZT+KNqJ60lwkF5RIBVK13WDct5tQKSQfRA7UsvxivM0RDFuKCBpvToG/piyVid6P8dJJ4fUHiZh3eVgf8ut08o1kcx9j9wenHtESjOSX9/efNUx3I8Chyzu5f7V4dC/CWZO9LgNoDMlL9N/5x94llJlQ2PlSG4CNq+WkKU=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1748594855; c=relaxed/simple;
	bh=OOPWvY82QJXP0j6KMTWjgBpN8Dg/4TrmkOuxtwo51dQ=;
	h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature;
	b=QLAGreQMUawozXT+sD45MMYmJjdQL+16CVYRncNCZwlEtC51/W7W7T771aPargEbdyJfOqJ6ctAi0xBrZkUBYPTLhzimpFooA0THHcJQ9rZLvvqh/VbKSneMNI4zaVAysCIhurAVYvxC/Kqusp+PCG9XLc3tbsaKv8hFLxTyG3A=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 7DFE7385840D
Date:	Fri, 30 May 2025 17:47:30 +0900
To:	cygwin AT cygwin DOT com
Subject:	Re: Crash or hang if SIGSEGV+SIGALRM are nested
Message-Id:	<20250530174730.7475a800c9f189b21ee0646e@nifty.ne.jp>
In-Reply-To:	<32cf9316-3e97-7fab-f975-851c3dfc25b9@t-online.de>
References:	<c4335d1d-5394-2a41-f06b-feb5c9fb1398 AT t-online DOT de>
	<20250528215707 DOT ddb72fb28122c3ed07da8c5b AT nifty DOT ne DOT jp>
	<20250529102846 DOT 8144f502c3f17decbe6700c1 AT nifty DOT ne DOT jp>
	<76940263-49e8-1b4a-17f2-11f5545014ab AT t-online DOT de>
	<20250530015410 DOT e8c4808c7947682b3309fbe7 AT nifty DOT ne DOT jp>
	<32cf9316-3e97-7fab-f975-851c3dfc25b9 AT t-online DOT de>
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
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>
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>

On Thu, 29 May 2025 20:01:31 +0200
Christian Franke wrote:
> Takashi Yano via Cygwin wrote:
> > On Thu, 29 May 2025 17:32:19 +0200
> > Christian Franke wrote:
> > ...
> >> I still don't fully understand why a SIGSEGV triggered by an instruction
> >> could interrupt a SIGALRM handler.
> >> https://sourceware.org/pipermail/cygwin/2025-May/258145.html
> >>
> >> I guess such behavior is valid from the POSIX point of view, but it is
> >> at least unexpected. If the SIGALRM handler is already running, it
> >> should have interrupted the thread such that the instruction triggering
> >> the segfault is not executed until the SIGALRM handler returns.
> > I try to explain what is happing using the figure below.
> >
> >     <<<<<< Main thread >>>>>>                       < Signal Thread >
> >                                              SIGNAL
> >    main()   handler1() handler2()             QUEUE    wait_sig()
> >      |          .          .                    |          |
> >      |          .          .       ALRM         |          |
> >      +----------------------------------------->|   ALRM   |
> >      |          .          .       SEGV         +--------->|
> >      X----------------------------------------->|          |
> >      |          .       arm ALRM                |          |
> >      +----------+ <----------------------------------------+
> >                 |          .                    |   SEGV   |
> >                 |          .                    +--------->|
> >                 |          .                    |          |
> >                 |          .      arm SEGV      |          |
> >                 +----------+ <-----------------------------+
> >                 .          |                    |          |
> >           longjmp()        |                    |          |
> >      +---------------------+                    |          |
> >      |          .          .                    |          |
> >      |          .          .                    |          |
> >
> > The point is the exception handler does not arm SIGSEGV handler
> > directly. It just pushes the SIGSEGV into the signal queue.
> > The signal thread reads the queue and process it asynchronously,
> > and arms the handler().
> >
> 
> I see. Thanks for nice explanation!
> 
> I created an issue at stress-ng upstream because at least the --mprotect 
> test is affected:
> https://github.com/ColinIanKing/stress-ng/issues/529

Thanks!

BTW, do you think this is the right thing?
https://github.com/RISCV-Tools/stress-ng/commit/bf24393357cde137bb8e7b38f917f565946199fd

I think the patch should set SIGSEGV mask on SIGALRM.

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

- Raw text -