DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52DBhTlp097264
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 28ECF3858039
Date: Thu, 13 Mar 2025 20:42:52 +0900
To: cygwin@cygwin.com
Subject: Re: cygwin 3.6.0: No signals received after swapcontext() is used
Message-Id: <20250313204252.e340f0de50838f161b0e8323@nifty.ne.jp>
In-Reply-To: <c0000d72-2b39-2647-648f-9006bed1273e@t-online.de>
References: <ec6e2050-953f-0d47-c385-cfa598566291@t-online.de>
 <Z8nxYCxthcsMVqzL@calimero.vinschen.de>
 <bf4eb7e1-66e3-e1f9-67e2-c4d4a75ff6c8@t-online.de>
 <Z864NNIyYwOWk5I3@calimero.vinschen.de>
 <373993a3-9f0f-9750-60a0-950f83b3b0b5@t-online.de>
 <Z9Gooi9C1UcJBuMW@calimero.vinschen.de>
 <Z9Gw6inr56cd4TGe@calimero.vinschen.de>
 <Z9G1BBjghen0kWvx@calimero.vinschen.de>
 <c0000d72-2b39-2647-648f-9006bed1273e@t-online.de>
Mime-Version: 1.0
Precedence: list
From: Takashi Yano via Cygwin <cygwin@cygwin.com>
Reply-To: Takashi Yano <takashi.yano@nifty.ne.jp>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

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@vinschen.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?

-- 
Takashi Yano <takashi.yano@nifty.ne.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