DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52CG780G3868678
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 52CG780G3868678
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=fcliLlwp
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4C415385843B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1741795627;
	bh=C/dtyLc3AfYklXR8qJ+HwHtQwBYzNDTof+YvAa+EOFE=;
	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=fcliLlwpev1Pmx6ZXUbrQ6eoixGZf3sR4y2R4ZgSuBVtH3hwBN0RDIrmlESXS60nk
	 M3pDCXnp8a/6S9EC1QoF9AhLy4Pa/MkpKsTWP2BSBr/SYcimvjRqtkTScUs1gFsYWG
	 R7J1jHgS1IYrvUqNqMVMebp0jlMzq/tmYklwehPE=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7E8773858D21
Date: Wed, 12 Mar 2025 17:06:02 +0100
To: cygwin AT cygwin DOT com
Subject: Re: cygwin 3.6.0: No signals received after swapcontext() is used
Message-ID: <Z9Gw6inr56cd4TGe@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>
 <Z9Gooi9C1UcJBuMW AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <Z9Gooi9C1UcJBuMW@calimero.vinschen.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 12 16:30, Corinna Vinschen via Cygwin wrote:
> 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.

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.


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