DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52CFVlcY3855128
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 52CFVlcY3855128
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=rjG2ju+n
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7D3C13858282
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1741793505;
	bh=X5TUxmtkp+F3GBedBopDniH+p94J6g9Z1/3QeUENbss=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=rjG2ju+nQdQQm635vsDyxqA6tburaKzuhd7q2oNWF8pRwb8OfEPHAGvFpXv/dhlkq
	 5MEnaH6WXYn8lVYYMzA0iQXWnXolk2MJ8pOiwYYMgA3HJ5Es5hO72UIYwVD+EV0+7A
	 gDtaEZ9HfNCSMSIEElQ9eKDkziKP42daiDyeONCc=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1629F3858C5F
Date: Wed, 12 Mar 2025 16:30:42 +0100
To: cygwin AT cygwin DOT com
Subject: Re: cygwin 3.6.0: No signals received after swapcontext() is used
Message-ID: <Z9Gooi9C1UcJBuMW@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
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>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <373993a3-9f0f-9750-60a0-950f83b3b0b5@t-online.de>
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: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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 Mar 11 12:32, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > It's not quite clear to me why signal handling should be broken if
> > setcontext is used inside a signal handler.  The incyg flag is false
> > when running the signal handler and that's correct.  Theoretically a
> > running signal handler is not different from other process code.
> > 
> > Do you have an STC, by any chance?
> 
> 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.


Corinna

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