DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 52D9fVU0059106
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 52D9fVU0059106
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=xY4CuXSc
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 6F4233857B96
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1741858889;
	bh=OvKrlaQWbCMtPtrtzml2sMaaWm7efaydiR2GNG83YaY=;
	h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=xY4CuXScq0PCeARf9WArwDZerlk6YhKOGEN9hZlCS58NMoev0L/gubaJaHKpdCqKL
	kzI4qstPfKsuD3mzqXY0QVrP9RsQKTW49BQQXZUi9dlyzzh/HK0OqLJTJ0mOTuDec8
	M26S3d8D37JUC8DyhXdTFYbDl3Mybsa9u+v6OgvM=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org DB4833858D33
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org DB4833858D33
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741858857; cv=none;
	b=HXuE08ia5gCXHQg85OBbEBMSI27Hn9Px22uuNJ5DaV0kabcBVOl4Z0MPV7tMtSlCWWgmxgsB2dq/R9fu3qInQsR2jKmA883x0oYgrSGyvygWehTvo083CI3uIaZdp72a4AoTHtr5qPewrPkTlo0uOCyl958ZgA0xstQbDTUyT1E=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1741858857; c=relaxed/simple;
	bh=wuUMfjNUtNWdkSeE+t4bGgq5hD18Z1zn2RaYouC0jSM=;
	h=Subject:To:From:Message-ID:Date:MIME-Version;
	b=gwTCN7Ge5g+zc4+NUwrmwBDfiB/XcsNHr24dPlIyJwGBpQ5x8U4iFJOcVFeijQXuj/ZzpKmQ+D7wsq+wMBNLyr6EB8GEKQNhpi+ghQYRL7YLzUY2VFNuYM6VsC+uK/LPBJDSEUWzeHfj3VHhlJPsscqDqR8IuaMxUYN7MAXSvHw=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org DB4833858D33
Subject:	Re: cygwin 3.6.0: No signals received after swapcontext() is used
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>
	<Z9Gw6inr56cd4TGe AT calimero DOT vinschen DOT de>
	<Z9G1BBjghen0kWvx AT calimero DOT vinschen DOT de>
Message-ID:	<c0000d72-2b39-2647-648f-9006bed1273e@t-online.de>
Date:	Thu, 13 Mar 2025 10:40:48 +0100
User-Agent:	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101
	SeaMonkey/2.53.20
MIME-Version:	1.0
In-Reply-To:	<Z9G1BBjghen0kWvx@calimero.vinschen.de>
X-TOI-EXPURGATEID:	150726::1741858849-6EFFB594-7DEDBB8C/0/0 CLEAN NORMAL
X-TOI-MSGID:	12f7863b-4d55-4dd3-af5e-c1a056b1e713
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:	Christian Franke via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	cygwin AT cygwin DOT com
Cc:	Christian Franke <Christian DOT Franke AT t-online DOT de>
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>

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.

-- 
Thanks,
Christian


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