uc_sigmask set in a sigaction signal handler not honored

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

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

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

malloc(0) crashes with SIGABRT

[Petr Skočík]

https://twitter.com/sortiecat/status/1170697927804817412

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

malloc(0) crashing with SIGABRT

[Petr Skočík]

There's been a twitter discussion on how different POSIX platforms
handle malloc(0): https://twitter.com/sortiecat/status/1170697927804817412 .

As for Cygwin, the answer appears to be "not well", but this should be
easy to fix.

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

Re: malloc(0) crashing with SIGABRT

[Brian Inglis]

On 2019-09-09 11:13, Petr Skočík wrote:
> There's been a twitter discussion on how different POSIX platforms
> handle malloc(0): https://twitter.com/sortiecat/status/1170697927804817412 .
> 
> As for Cygwin, the answer appears to be "not well", but this should be
> easy to fix.

POSIX SUS V4 2018 says:

"RETURN VALUE

Upon successful completion with size not equal to 0, malloc() shall return a
pointer to the allocated space. If size is 0, either:

	A null pointer shall be returned [CX] [Option Start]  and errno may be set to
an implementation-defined value, [Option End] or

	A pointer to the allocated space shall be returned. The application shall
ensure that the pointer is not used to access an object.

Otherwise, it shall return a null pointer [CX] [Option Start]  and set errno to
indicate the error. [Option End]"

The second option could be implemented by a pointer to an unmapped page, or a
reference to an inaccessible mmap-ed area length zero.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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: malloc(0) crashing with SIGABRT

[Kaz Kylheku]

On 2019-09-11 20:59, Brian Inglis wrote:
> On 2019-09-09 11:13, Petr Skočík wrote:
>> There's been a twitter discussion on how different POSIX platforms
>> handle malloc(0): 
>> https://twitter.com/sortiecat/status/1170697927804817412 .
>> 
>> As for Cygwin, the answer appears to be "not well", but this should be
>> easy to fix.
> 
> POSIX SUS V4 2018 says:
> 
> "RETURN VALUE
> 
> Upon successful completion with size not equal to 0, malloc() shall 
> return a
> pointer to the allocated space. If size is 0, either:
> 
> 	A null pointer shall be returned [CX] [Option Start]  and errno may be 
> set to
> an implementation-defined value, [Option End] or
> 
> 	A pointer to the allocated space shall be returned. The application 
> shall
> ensure that the pointer is not used to access an object.
> 
> Otherwise, it shall return a null pointer [CX] [Option Start]  and set 
> errno to
> indicate the error. [Option End]"
> 
> The second option could be implemented by a pointer to an unmapped 
> page, or a
> reference to an inaccessible mmap-ed area length zero.

That's easy: the null pointer, plus some small offset that observes 
alignment, like 16.

(Alignment is important even if the memory isn't accessed, because 
nonportable programs
depend on it for other reasons, like being able to use the least 
significant few bits
of a pointer for tagging.)



--
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: malloc(0) crashing with SIGABRT

[Ken Brown]

On 9/9/2019 1:13 PM, Petr Skočík wrote:
> There's been a twitter discussion on how different POSIX platforms
> handle malloc(0): https://twitter.com/sortiecat/status/1170697927804817412 .
> 
> As for Cygwin, the answer appears to be "not well", but this should be
> easy to fix.

Can you show how you produced a crash?  It works fine for me with the following 
test program:

$ cat malloc_zero.c
#include <stdlib.h>
#include <stdio.h>

int
main ()
{
   printf ("malloc (0) = %p\n", malloc (0));
}

$ gcc -Wall -o malloc_zero malloc_zero.c

$ ./malloc_zero.exe
malloc (0) = 0x8000003c0

[This is on 64-bit Cygwin.  It's the same on 32-bit, but with a different address.]

Ken

--
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: malloc(0) crashing with SIGABRT

[Brian Inglis]

On 2019-09-11 23:18, Kaz Kylheku wrote:
> On 2019-09-11 20:59, Brian Inglis wrote:
>> On 2019-09-09 11:13, Petr Skočík wrote:
>>> There's been a twitter discussion on how different POSIX platforms
>>> handle malloc(0): https://twitter.com/sortiecat/status/1170697927804817412 .
>>>
>>> As for Cygwin, the answer appears to be "not well", but this should be
>>> easy to fix.
>>
>> POSIX SUS V4 2018 says:
>>
>> "RETURN VALUE
>>
>> Upon successful completion with size not equal to 0, malloc() shall return a
>> pointer to the allocated space. If size is 0, either:
>>
>>     A null pointer shall be returned [CX] [Option Start]  and errno may be set to
>> an implementation-defined value, [Option End] or
>>
>>     A pointer to the allocated space shall be returned. The application shall
>> ensure that the pointer is not used to access an object.
>>
>> Otherwise, it shall return a null pointer [CX] [Option Start]  and set errno to
>> indicate the error. [Option End]"
>>
>> The second option could be implemented by a pointer to an unmapped page, or a
>> reference to an inaccessible mmap-ed area length zero.
> 
> That's easy: the null pointer, plus some small offset that observes alignment,
> like 16.

It's more a question of what the NULL pointer maps to: I liked systems mapping
NULL pointers to inaccessible pages; and compilers that allow bss to be filled
with bits: carelessness got caught fast!

> (Alignment is important even if the memory isn't accessed, because
> nonportable programs depend on it for other reasons, like being able to use
> the least significant few bits of a pointer for tagging.)

[Keeping tag bits or a byte elsewhere is less overhead than the instructions
required to sanitize tainted pointers before use, assuming all the code
remembers to do so, and those programs deserve what they get! Blargh!]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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: malloc(0) crashing with SIGABRT

[Ken Brown]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 797 bytes --]

On 9/13/2019 3:38 AM, Petr Skočík wrote:
> On 9/12/19 6:12 PM, Ken Brown wrote:
>> gcc -Wall -o malloc_zero malloc_zero.c
> 
> My apologies. It was my own stupid mistake.
> 
> (
> I had
> 
> gcc -include stdlib.h -xc - <<<'int main(){ }' && ./a.out; echo $?
> 
> where I would normally run $aout which in my shell setup is
> a.exe on cygwin and a.out elsewhere, but this time I accidentally
> typed a.out and I happened to have a Linux a.out there and that
> was causing the crash.
> )

No problem.  I'm glad to hear there's no Cygwin issue.

Ken
\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB

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

[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