DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 52DCWv35114469
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 52DCWv35114469
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=uK17GfgH
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 17F4D3857B9F
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1741869176;
	bh=RrmRwFXgCoSEhieCmBcMhy41HCqSXsq8ZpMhXr++H0M=;
	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=uK17GfgH40jMn8mbIo5iUJYtAnkH5XanOKXRfdzaAn2d1AMuKlgbV1OP9vZ+trMd5
	KGLDfRwTU8AlbrnxTpZKsu4bAJzVHvZC04MgZxLTeG79evs1lYbWxfB3KlhCqd00OE
	oPQYvfiUUM54FwfeWjeIEpXpkvOTeYh3zdWtN5+A=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org C33BA3858D33
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org C33BA3858D33
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741869112; cv=none;
	b=G5rhVU3Xm6Wjgj9LeDSO/03Bq/1+sFFGNNZynGqMWOfuVyB1+EK9JAmbl0JtpXF402rxnu9+zD6855gyWEAcfU2JcnyjfUznFUt6NKqfDn8uELVIQOjwnxEiXw+7/f48tnf3VROoitINJiBeVcuoLZMVc9YNFIomNpynmZ0HbnE=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1741869112; c=relaxed/simple;
	bh=zH4KCSxDMk2OSDedgMr6JCTh/hwv/rGndDFwX3tvceI=;
	h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature;
	b=gifaagMQTIH6kXYTFz8W6lYx3LVgQpum5vP/MbTydc98W1h2I9EUDUvtziixsYg96unPdHuWivc6Mup7CgDx/6BbTr9D4Qwt1RJmc8OzvwNeT7NsbtJQseN7qpeSfiIxRN/ntuoEKbWbzcTpJ2HzEyPioZwBo945Cz405sR98bM=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org C33BA3858D33
Date:	Thu, 13 Mar 2025 21:31:48 +0900
To:	cygwin AT cygwin DOT com
Subject:	Re: cygwin 3.6.0: No signals received after swapcontext() is used
Message-Id:	<20250313213148.6c2cb65f5e692005f28d3d2c@nifty.ne.jp>
In-Reply-To:	<20250313204252.e340f0de50838f161b0e8323@nifty.ne.jp>
References:	<ec6e2050-953f-0d47-c385-cfa598566291 AT t-online DOT de>
	<Z8nxYCxthcsMVqzL AT calimero DOT vinschen DOT de>
	<bf4eb7e1-66e3-e1f9-67e2-c4d4a75ff6c8 AT t-online DOT de>
	<Z864NNIyYwOWk5I3 AT calimero DOT vinschen DOT de>
	<373993a3-9f0f-9750-60a0-950f83b3b0b5 AT t-online DOT de>
	<Z9Gooi9C1UcJBuMW AT calimero DOT vinschen DOT de>
	<Z9Gw6inr56cd4TGe AT calimero DOT vinschen DOT de>
	<Z9G1BBjghen0kWvx AT calimero DOT vinschen DOT de>
	<c0000d72-2b39-2647-648f-9006bed1273e AT t-online DOT de>
	<20250313204252 DOT e340f0de50838f161b0e8323 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
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, 13 Mar 2025 20:42:52 +0900
Takashi Yano wrote:
> Hi Corinna,
> 
> On Thu, 13 Mar 2025 10:40:48 +0100
> Christian Franke wrote:
> > Corinna Vinschen via Cygwin wrote:
> > > On Mar 12 17:06, Corinna Vinschen via Cygwin wrote:
> > >> On Mar 12 16:30, Corinna Vinschen via Cygwin wrote:
> > >>> On Mar 11 12:32, Christian Franke via Cygwin wrote:
> > >>>> The attached testcase should test the following use cases of setcontext:
> > >>>> - call from regular user space
> > >>>> - call from a signal handler interrupting user space
> > >>>> - call from a signal handler interrupting a system call
> > >>>>
> > >>>> It works as expected ... until the signal count reaches 256. Then signals
> > >>>> are again only delivered from inside of a system call.
> > >>>> [...]
> > >>>> Interesting... Hmm... is there some 8-bit counter which overflows and then
> > >>>> stucks at 0xff or 0x00?
> > >>> It's a kind of stack overflow.  Kind of, because it's not the normal
> > >>> thread stack, but a special signal stack in the _cygtls area.
> > >>>
> > >>> When interrupting a running thread to call a signal handler, the context
> > >>> of the thread is changed to restart execution in an assembler function
> > >>> called sigdelayed().  The original IP of the thread is pushed on the
> > >>> aforementioned signal stack.  Sigdelayed() calls the signal handler.  On
> > >>> return it pops the original IP from the signal stack and continues the
> > >>> thread.
> > >>>
> > >>> Now guess what happens if the signal handler bails out with longjmp or
> > >>> setcontext/swapcontext.
> > >>>
> > >>> The signal handler never returns to the sigdelayed() function, the
> > >>> original address is never poped from the signal stack, and the signal
> > >>> stack has a max. size of 256 address entries...
> > >>>
> > >>> Theoretically, a small update to sigdelayed() would fix the issue: ather
> > >>> then poing the original IP from the signal stack after calling the
> > >>> handler, it should pop the IP prior to calling the handler.  That would
> > >>> avoid filling up the signal stack when long-jumping out of the signal
> > >>> handler.  It should store the IP in one of the callee-saved registers.
> > >>> %r13 is unused in sigdelayed so far.
> > >>>
> > >>> However, even if we do this, there's still the problem that sigdelayed()
> > >>> itself takes space on the stack.  If you longjmp/setcontext out of the
> > >>> handler, the thread's normal stack will fill up with dead storage of the
> > >>> sigdelayed() function, and there's no way out of this trap.  We can't
> > >>> restore the stack before the handler returns.
> > >>>
> > >>> So either way, at one point you get a stack overflow one way or the
> > >>> other.
> > >>>
> > >>> The signal stack overflow is actually rather harmless in comparison
> > >>> to a real stack overflow.
> > >>>
> > >>> If you have any idea how to avoid the real stack overflow, I'd be
> > >>> all ears.
> > >> Looks like this isn't really a problem with setcontext.  It always
> > >> corrects the stack pointer as well.  Apparently I haven't thought
> > >> long enough about this.
> > >>
> > >> I have a patch for sigdelayed() in the loop, stay tuned.
> > > Just pushed.  Try cygwin-3.6.0-0.430.ga942476236b5 in a bit.
> > 
> > Problem does no longer occur. Also tested with 'kill -INT PID && sleep 
> > 0.01' in a loop.
> 
> After the commit:
> 
> commit a942476236b5e39bf30c533d08df7392e326a4c6 (origin/master, origin/main, origin/HEAD)
> Author: Corinna Vinschen <corinna AT vinschen DOT de>
> Date:   Wed Mar 12 17:17:31 2025 +0100
> 
>     Cygwin: sigdelayed: pop return address from signal stack earlier
> 
> Christians test case: timersig.c no longer works even with my v3 patches.
> I suspect it is because pop(), retaddr() are not working as intended in
> call_signal_handler() with this commit.
> 
> Could you please have a look?


What about following patch instead of your sigdelayed patch?

diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index c9fe6a386..ceb47e52e 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -1758,6 +1758,13 @@ _cygtls::call_signal_handler ()
       reset_signal_arrived ();
       incyg = false;
       current_sig = 0;	/* Flag that we can accept another signal */
+
+      /* We have to fetch the original return address from the signal stack
+	 prior to calling the signal handler.  This avoids filling up the
+	 signal stack if the signal handler longjumps (longjmp/setcontext). */
+      DWORD64 retaddr1 = pop ();
+      DWORD64 retaddr2 = stackptr > stack ? retaddr () : 0;
+      __tlsstack_t *ptr = stackptr;
       unlock ();	/* unlock signal stack */
 
       /* Alternate signal stack requested for this signal and alternate signal
@@ -1834,6 +1841,26 @@ _cygtls::call_signal_handler ()
 	   signal handler. */
 	thisfunc (thissig, &thissi, thiscontext);
 
+      lock ();
+      if (stackptr == ptr)
+	push (retaddr1);
+      else if (stackptr == ptr + 1)
+	{
+	  DWORD64 retaddr3 = pop();
+	  push (retaddr1);
+	  push (retaddr3);
+	}
+      else if (stackptr == ptr - 1)
+	{
+	  if (retaddr2)
+	    push (retaddr2);
+	  else
+	    stackptr++;
+	}
+      else
+	api_fatal ("Signal stack corrupted?.");
+      unlock ();
+
       incyg = true;
 
       set_signal_mask (_my_tls.sigmask, (this_sa_flags & SA_SIGINFO)

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