Re: uc_sigmask set in a sigaction signal handler not honored

Re: uc_sigmask set in a sigaction signal handler not honored

[Petr Skočík]

> On Apr  3 14:15, Corinna Vinschen wrote:
> > On Apr  3 11:27, Petr Skočík wrote:
> > > Hi. Correct me if I'm wrong but POSIX appears to define
> > >
> > > https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html
> > >
> > > as, among other things, containing the field:
> > >
> > > sigset_t    uc_sigmask  the set of signals that are blocked when this
> > >                         context is active
> > >
> > > and it also specifies that the third argument to a .sa_sigaction
> > > signal handler is a ucontext_t* cast to void*.
> > >
> > > So it should follow that doing
> > >
> > > void act(int Sig, siginfo_t *Info, void *Uctx)
> > > {
> > > 	ucontext_t *uctx = Uctx;
> > > 	sigfillset(&uctx->uc_sigmask);
> > > }
> > >
> > > from a signal handler should alter the signal mask of the thread the
> > > signal ran on.
> > >
> > > This is how Linux and MacOS behave, but not CygWin, as the following
> > > program shows:
> >
> > What you're asking for is really complicated.
> >
> > The context given to act is the context at the time the signal function
> > is called.  In Cygwin (lower case w) this is a copy of the context.
> >
> > sigfillset() has not the faintest clue where this context comes from, it
> > just sets the signal mask value without taking any further action.
> >
> > There are no provisions to control if the called function changes the
> > context, other than via setcontext / swapcontext, and I don't see that
> > POSIX requires anything else.  Both functions change the current
> > thread's sigmask according to the value of uc_sigmask.
>
> Or maybe I'm just dumb.  Would it suffice if the thread's signal mask is
> changed to uc_sigmask when the signal function returns?
>
>
> Corinna

Thanks for the feedback.

> Would it suffice if the thread's signal mask is
> changed to uc_sigmask when the signal function returns?

That is the idea. It's what Linux and MacOS do.

Petr Skocik

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: uc_sigmask set in a sigaction signal handler not honored

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2705 bytes --]

On Apr  3 16:39, Petr Skočík wrote:
> > On Apr  3 14:15, Corinna Vinschen wrote:
> > > On Apr  3 11:27, Petr Skočík wrote:
> > > > Hi. Correct me if I'm wrong but POSIX appears to define
> > > >
> > > > https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html
> > > >
> > > > as, among other things, containing the field:
> > > >
> > > > sigset_t    uc_sigmask  the set of signals that are blocked when this
> > > >                         context is active
> > > >
> > > > and it also specifies that the third argument to a .sa_sigaction
> > > > signal handler is a ucontext_t* cast to void*.
> > > >
> > > > So it should follow that doing
> > > >
> > > > void act(int Sig, siginfo_t *Info, void *Uctx)
> > > > {
> > > > 	ucontext_t *uctx = Uctx;
> > > > 	sigfillset(&uctx->uc_sigmask);
> > > > }
> > > >
> > > > from a signal handler should alter the signal mask of the thread the
> > > > signal ran on.
> > > >
> > > > This is how Linux and MacOS behave, but not CygWin, as the following
> > > > program shows:
> > >
> > > What you're asking for is really complicated.
> > >
> > > The context given to act is the context at the time the signal function
> > > is called.  In Cygwin (lower case w) this is a copy of the context.
> > >
> > > sigfillset() has not the faintest clue where this context comes from, it
> > > just sets the signal mask value without taking any further action.
> > >
> > > There are no provisions to control if the called function changes the
> > > context, other than via setcontext / swapcontext, and I don't see that
> > > POSIX requires anything else.  Both functions change the current
> > > thread's sigmask according to the value of uc_sigmask.
> >
> > Or maybe I'm just dumb.  Would it suffice if the thread's signal mask is
> > changed to uc_sigmask when the signal function returns?
> 
> Thanks for the feedback.
> 
> > Would it suffice if the thread's signal mask is
> > changed to uc_sigmask when the signal function returns?
> 
> That is the idea. It's what Linux and MacOS do.

I pushed a patch which, for now, only sets the thread's sigmask to the
value set by the signal handler in uc_sigmask.

I have code in the loop allowing the signal handler to change the entire
context.  The code the signal handler returns to would check if the
handler changed the context and call setcontext if so.  However, I'm
reluctant to push it without having some serious, simple testcase.

As for restoring the thread signal mask, I uploaded new developer
snapshots to https://cygwin.com/snapshots/ for testing.  Please give
them a try.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: uc_sigmask set in a sigaction signal handler not honored

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]

On Apr  3 14:15, Corinna Vinschen wrote:
> On Apr  3 11:27, Petr Skočík wrote:
> > Hi. Correct me if I'm wrong but POSIX appears to define
> > 
> > https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html
> > 
> > as, among other things, containing the field:
> > 
> > sigset_t    uc_sigmask  the set of signals that are blocked when this
> >                         context is active
> > 
> > and it also specifies that the third argument to a .sa_sigaction
> > signal handler is a ucontext_t* cast to void*.
> > 
> > So it should follow that doing
> > 
> > void act(int Sig, siginfo_t *Info, void *Uctx)
> > {
> > 	ucontext_t *uctx = Uctx;
> > 	sigfillset(&uctx->uc_sigmask);
> > }
> > 
> > from a signal handler should alter the signal mask of the thread the
> > signal ran on.
> > 
> > This is how Linux and MacOS behave, but not CygWin, as the following
> > program shows:
> 
> What you're asking for is really complicated.
> 
> The context given to act is the context at the time the signal function
> is called.  In Cygwin (lower case w) this is a copy of the context.
> 
> sigfillset() has not the faintest clue where this context comes from, it
> just sets the signal mask value without taking any further action.
> 
> There are no provisions to control if the called function changes the
> context, other than via setcontext / swapcontext, and I don't see that
> POSIX requires anything else.  Both functions change the current
> thread's sigmask according to the value of uc_sigmask.

Or maybe I'm just dumb.  Would it suffice if the thread's signal mask is
changed to uc_sigmask when the signal function returns?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: uc_sigmask set in a sigaction signal handler not honored

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

On Apr  3 11:27, Petr Skočík wrote:
> Hi. Correct me if I'm wrong but POSIX appears to define
> 
> https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html
> 
> as, among other things, containing the field:
> 
> sigset_t    uc_sigmask  the set of signals that are blocked when this
>                         context is active
> 
> and it also specifies that the third argument to a .sa_sigaction
> signal handler is a ucontext_t* cast to void*.
> 
> So it should follow that doing
> 
> void act(int Sig, siginfo_t *Info, void *Uctx)
> {
> 	ucontext_t *uctx = Uctx;
> 	sigfillset(&uctx->uc_sigmask);
> }
> 
> from a signal handler should alter the signal mask of the thread the
> signal ran on.
> 
> This is how Linux and MacOS behave, but not CygWin, as the following
> program shows:

What you're asking for is really complicated.

The context given to act is the context at the time the signal function
is called.  In Cygwin (lower case w) this is a copy of the context.

sigfillset() has not the faintest clue where this context comes from, it
just sets the signal mask value without taking any further action.

There are no provisions to control if the called function changes the
context, other than via setcontext / swapcontext, and I don't see that
POSIX requires anything else.  Both functions change the current
thread's sigmask according to the value of uc_sigmask.


HTH,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

uc_sigmask set in a sigaction signal handler not honored

[Petr Skočík]

Hi. Correct me if I'm wrong but POSIX appears to define

https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html

as, among other things, containing the field:

sigset_t    uc_sigmask  the set of signals that are blocked when this
                        context is active

and it also specifies that the third argument to a .sa_sigaction
signal handler is a ucontext_t* cast to void*.

So it should follow that doing

void act(int Sig, siginfo_t *Info, void *Uctx)
{
	ucontext_t *uctx = Uctx;
	sigfillset(&uctx->uc_sigmask);
}

from a signal handler should alter the signal mask of the thread the
signal ran on.

This is how Linux and MacOS behave, but not CygWin, as the following
program shows:

#include <signal.h>
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
#include <sys/time.h>
void prmask(void)
{
	sigset_t mask; pthread_sigmask(SIG_SETMASK,0,&mask);
	for(int i=1; i<=64; i++){ printf("%d", sigismember(&mask,i)); } puts("");
}
void act(int Sig, siginfo_t *Info, void *Uctx)
{
	ucontext_t *uctx = Uctx;
	sigfillset(&uctx->uc_sigmask);
}
int main()
{
	struct sigaction sa;
	sa.sa_sigaction = act;
	sa.sa_flags = SA_SIGINFO;
	sigfillset(&sa.sa_mask);

	prmask();
	sigaction(SIGINT,&sa,0);
	sigaction(SIGALRM,&sa,0);
	if(1)
		setitimer(ITIMER_REAL,&(struct itimerval){.it_value={.tv_usec=10000}},0);
	pause();
	prmask();
}

I think this is a bug, so I'm reporting it. Do you think it can be fixed
in the near future?

Best regards,
Petr Skocik


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple