This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix invalid sigprocmask call


On 03/24/2017 12:23 PM, Yousong Zhou wrote:
> On 24 March 2017 at 18:47, Pedro Alves <palves@redhat.com> wrote:
>> On 03/24/2017 03:01 AM, Yousong Zhou wrote:
>>> The POSIX document says
>>>
>>>     The pthread_sigmask() and sigprocmask() functions shall fail if:
>>>
>>>     [EINVAL]
>>>     The value of the how argument is not equal to one of the defined values.
>>>
>>> and this is how musl-libc is currently doing.  Fix the call to be safe
>>> and correct
>>>
>>>  [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_sigmask.html
>>>
>>
>> I don't agree.  It's a musl bug.  Please fix it / file a musl bug.
> 
> I already did that before sending to gdb-patches
> 
>   http://www.openwall.com/lists/musl/2017/03/24/1
> 
> I am aware of the fact that the current code works with glibc and mac
> osx 10.11.6.  The Linux kernel code at the moment also accepts the
> call with how==0

Cool.

> 
> But this is more about interpretation of POSIX document itself.  And
> it says, clearly without pre-condition words or ambiguity in the
> ERRORS section of that page, to return EINVAL if how is not equal to
> one of the defined values.

The standard wasn't built on a vacuum.  It starts by ratifying common
implementation behavior.  If no historical implementation behaves like what
you're suggesting, what's the point of enforcing that, when it's clearly
NOT the intent?  You're just causing porting pain for no good reason.
Please file a bug against the standard to have the error section clarified instead.

> 
> I also tried to find some posix-compliant testsuite and to search the
> github code for samples of pthread_sigmask call.  The first I came
> across was the following code snippet at link
> https://github.com/juj/posixtestsuite/blob/master/conformance/interfaces/pthread_sigmask/8-1.c#L57
> 
>         pthread_sigmask(SIG_BLOCK, NULL, &oactl);

The fact that that call includes SIG_BLOCK doesn't say whether
passing 0 should be rejected.

So I cloned that repo, and did a quick grep.  And lo:

https://github.com/juj/posixtestsuite/blob/26372421f53aeeeeeb4b23561c417886f1930ef6/conformance/interfaces/fork/12-1.c#L187

		/* Examine the current blocked signal set. USR1 & USR2 shall be present */
		ret = sigprocmask( 0, NULL, &mask );

		if ( ret != 0 )
		{
			UNRESOLVED( errno, "Sigprocmask failed in child" );
		}

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]