On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> On Thu, 13 Mar 2025 20:42:52 +0900
> Takashi Yano wrote:
> > After the commit:
> >
> > commit a942476236b5e39bf30c533d08df7392e326a4c6 (origin/master,
> > origin/main, origin/HEAD)
> > Author: Corinna Vinschen <cori...@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.
Sigh.
> > Could you please have a look?
>
> 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?
Thanks,
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
