cygwin 3.6.0: No signals received after swapcontext() is used

Takashi Yano takashi.yano@nifty.ne.jp
Fri Mar 14 03:56:32 GMT 2025


On Fri, 14 Mar 2025 08:12:36 +0900
Takashi Yano wrote:
> 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?

No, I was wrong. Every time when call_signal_handler() is
called, the _cygtls::stack is pulled, so, it always becomes
empty. Therefore, stackptr - orig_stackptr is never more
than two.

So, _cygtls::stack needs only two spaces maximum. Please
look attached v2 patch. Do I overlook something?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: v2-0001-Cygwin-signals-pop-return-address-from-signal-sta.patch
URL: <https://cygwin.com/pipermail/cygwin/attachments/20250314/98d51bf2/attachment.ksh>


More information about the Cygwin mailing list