DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 52DNDner524137
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 52DNDner524137
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=N7txy2GG
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 9BCD63857BA3
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1741907628;
	bh=oSdc/SqS3Zl45u+oYeZENxeYasPIo9TnzhfbS0gdljo=;
	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=N7txy2GGpG1ieNXmeFQiXRec6300T55mTLiEVi0tqI2GD4sw4XOJRCzHXT0nARcHA
	0U01WrAhQaqFg282st5hk9AO6isbLY2H/HwTgUIF5IvqKqeaHdLME2xySkh+YXD91S
	KwlSdoPcxUYPkLGHQ+Fsj/Y6M39kHrI5Geogd5q8=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 8D2FB3858D39
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 8D2FB3858D39
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741907561; cv=none;
	b=CIunRUjYFhkn+gEyej9XMcgmdxJ0GDB/gKR5SSlsAdHLerJD3FqxBW5TU3eutGVr2XpKJrWPKLl0VuKKUSdNQYjuuVRYxrqke196nqRaGcQzhvpGheP+XAy7nraodBDNGRGDaLNth0P82uRkHkiZjJrSmPhSlAnORnARpbggLTg=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1741907561; c=relaxed/simple;
	bh=CZTOAfddtKvokv+u0F79DadBvhNyJ2twdL+9xwCpIsQ=;
	h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature;
	b=HIT6TzZnZBVTfG0Tqb8p0z1gYhcCb69WdibiL9kYrLj3SbR07YO/Nleelm4kQMyg3Y+8gzqS05Jf8KrsLtrZz10BBKgC4Yp5Ou4Dk5AyuH1HJAo79P4AuXvBompz8wenu9gXTsEZtAr0P4/3b2cVBM3Rbu+mbULWmUF+8+dviCQ=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 8D2FB3858D39
Date:	Fri, 14 Mar 2025 08:12:36 +0900
To:	cygwin AT cygwin DOT com
Subject:	Re: cygwin 3.6.0: No signals received after swapcontext() is used
Message-Id:	<20250314081236.bbdb1da7d746745925cdc752@nifty.ne.jp>
In-Reply-To:	<Z9NgWcJyt9kS5lCG@calimero.vinschen.de>
References:	<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>
	<20250313213148 DOT 6c2cb65f5e692005f28d3d2c AT nifty DOT ne DOT jp>
	<Z9MIKWFS1q-TYojK AT calimero DOT vinschen DOT de>
	<Z9NgWcJyt9kS5lCG AT calimero DOT vinschen 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, 13 Mar 2025 23:46:49 +0100
Corinna Vinschen wrote:
> On Mar 13 17:30, Corinna Vinschen via Cygwin wrote:
> > On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> > > What about following patch instead of your sigdelayed patch?
> > > [...]
> > > @@ -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 ();
> > > +
> > 
> > This... looks confusing and desperately needs comments (or at least
> > I need comments).
> > 
> > stackptr == ptr + 1 occurs if another signal arrived while the handler
> > was running, but isn't there a chance that sigdelayed has been pushed
> > as well, i.e., stackptr == ptr + 2?
> > 
> > I have no idea how the stackptr == ptr - 1 situation is supposed to
> > happen, though.  `else stackptr++;' looks weird.  If you don't push a
> > known address, what do you expect retaddr() pointing to, afterwards?
> 
> I have a slighty changed version. This one treats anything other
> than 0, 1 or 2 new addresses on the stack as bug.  I really made
> an effort trying to come up with a situation where the signal
> stack underflows, but I just couldn't.  If I'm missing something,
> please explain how this may happen.
> 
> Apart from that, I attached my patch proposal.

I think the following is the right thing. This version pulls return
addresses completely (not only one) before calling signal handler.
I think, stackptr - orig_stackptr can be larger than 2 when
user code
  signal handler 1
    signal handler 2
      signal handler 3
        signal handler 4
        ret
      ret
    ret
  HERE <= stackptr - orig_stackptr == 3
  ret
Is this right?

diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index c9fe6a386..453f9fea3 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -1758,6 +1758,14 @@ _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). */
+      __tlsstack_t retaddrs[TLS_STACK_SIZE];
+      int n1 = stackptr - stack;
+      memcpy (retaddrs, stack, n1 * sizeof (__tlsstack_t));
+      stackptr = stack;
       unlock ();	/* unlock signal stack */
 
       /* Alternate signal stack requested for this signal and alternate signal
@@ -1834,6 +1842,15 @@ _cygtls::call_signal_handler ()
 	   signal handler. */
 	thisfunc (thissig, &thissi, thiscontext);
 
+      lock ();
+      int n2 = stackptr - stack;
+      if (n1 + n2 > TLS_STACK_SIZE)
+	api_fatal ("Signal stack exhausted.");
+      memcpy (retaddrs + n1, stack, n2 * sizeof (__tlsstack_t));
+      memcpy (stack, retaddrs, (n1 + n2) * sizeof (__tlsstack_t));
+      stackptr += n1;
+      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 -