Re: Fw: sigwait() breaks when straced

Re: Fw: sigwait() breaks when straced

[Roland McGrath]

The problem is not really "when straced", but when strace attaches.  In
fact, it's not even "when PTRACE_ATTACH'd".  It's actually the implicit
SIGSTOP that PTRACE_ATTACH causes.  If you simply suspend and resume the
program (with SIGSTOP or C-z), you get the same result.  So this report is
more properly identified as "signal stop breaks sigwait".  

However, there is in fact no bug here.  The test program is just wrong.
sigwait returns zero or an error number, as POSIX specifies.  Conversely,
sigtimedwait and sigwaitinfo either return 0 or set errno and return -1.
It is odd that the interfaces of related functions differ in this way,
but they do.


Thanks,
Roland

Re: Fw: sigwait() breaks when straced

[Dave Airlie]

> 
> However, there is in fact no bug here.  The test program is just wrong.
> sigwait returns zero or an error number, as POSIX specifies.  Conversely,
> sigtimedwait and sigwaitinfo either return 0 or set errno and return -1.
> It is odd that the interfaces of related functions differ in this way,
> but they do.

The someone should fix the manpage, it explicitly says
"The sigwait function never returns an error."

Which is clearly wrong if it can return EINTR...

Dave.

Re: Fw: sigwait() breaks when straced

[Jesper Juhl]

On 8/1/05, Dave Airlie <airlied@gmail.com> wrote:
> >
> > However, there is in fact no bug here.  The test program is just wrong.
> > sigwait returns zero or an error number, as POSIX specifies.  Conversely,
> > sigtimedwait and sigwaitinfo either return 0 or set errno and return -1.
> > It is odd that the interfaces of related functions differ in this way,
> > but they do.
> 
> The someone should fix the manpage, it explicitly says
> "The sigwait function never returns an error."
> 
> Which is clearly wrong if it can return EINTR...
> 

As I read SUSv3 , sigwait /can/ return error, but EINTR is not one
that it's supposed to ever return.

>From http://www.opengroup.org/onlinepubs/009695399/functions/sigwait.html :
...
ERRORS

    The sigwait() function may fail if:

    [EINVAL]
        The set argument contains an invalid or unsupported signal number.
...

EINVAL is the only defined error for sigwait.


Also, at the start of the thread Ulrich Drepper said  "The kernel
simply doesn't restart the function in case of a signal. It should do
this, though." .

I'm not quite sure you are right Ulrich. Given this little bit from
SUSv3 about SA_RESTART in the page describing sigaction (
http://www.opengroup.org/onlinepubs/009695399/functions/sigaction.html
) :

...
SA_RESTART
    This flag affects the behavior of interruptible functions; that
is, those specified to fail with errno set to [EINTR]. If set, and a
function specified as interruptible is interrupted by this signal, the
function shall restart and shall not fail with [EINTR] unless
otherwise specified. If the flag is not set, interruptible functions
interrupted by this signal shall fail with errno set to [EINTR].
...

by that definition, that interruptible functions are those "specified
to fail with errno set to [EINTR]", I don't see how sigwait can be
considered an interruptible function since it
a) doesn't set errno
b) doesn't even list EINTR as a defined error return
And if sigwait is not an interruptible function, then how would it be
correct for the kernel to restart it ?
Also, the sigwait page (linked above) also says that "The sigwait()
function shall select a pending signal from set, atomically clear it
from the system's set of pending signals, and return that signal
number in the location referenced by sig." - the word that stands out
to me here is "atomically" - how can it be atomic if it is allowed to
be interrupted by signals?

What am I missing?

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Fw: sigwait() breaks when straced

[Ulrich Drepper]

On 8/1/05, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> I'm not quite sure you are right Ulrich. Given this little bit from
> SUSv3 about SA_RESTART in the page describing sigaction (
> http://www.opengroup.org/onlinepubs/009695399/functions/sigaction.html
> ) :

It's not an official SA_RESTART since the syscall is defined to
support EINTR.  It's clear  that sigwait in this sense is not
interruptible.  Return EINTR from sigwait is only allowed by POSIX
since there is no contrary wording (unlike for the pthread functions).
 But if this clause would be used each and every syscall could return
EINTR and we would have to surround all syscalls with a loop.  Hence
the syscall should be restarted, not because SA_RESTART is set, but
because EINTR shouldn't be returned.

Now, Roland correctly said sigtimedwait and sigwaitinfo need to return
EINTR and we use one syscall for them all.  I overlook that part.  So,
I'll add the wrapper in the libc so that sigwait restarts on EINTR.

Re: Fw: sigwait() breaks when straced

[Ulrich Drepper]

On 7/31/05, Roland McGrath <roland@redhat.com> wrote:
> However, there is in fact no bug here.  The test program is just wrong.
> sigwait returns zero or an error number, as POSIX specifies.

No question, no error is detected incorrectly.

But sigwait is not a function specified with an EINTR error number. 
As I said before, this does not mean that EINTR cannot be returned. 
But it will create havoc among programs and it causes undefined
behavior wrt to SA_RESTART.  I think it is best to not have any
function for which EINTR is not a defined error to fail this way. 
This causes the least amount of surprises and unnecessary loops around
the userlevel call sites.

Re: Fw: sigwait() breaks when straced

[Roland McGrath]

> But sigwait is not a function specified with an EINTR error number. 
> As I said before, this does not mean that EINTR cannot be returned. 
> But it will create havoc among programs and it causes undefined
> behavior wrt to SA_RESTART.  I think it is best to not have any
> function for which EINTR is not a defined error to fail this way. 
> This causes the least amount of surprises and unnecessary loops around
> the userlevel call sites.

We use the same rt_sigtimedwait system call for sigtimedwait and
sigwaitinfo, which do list EINTR for the case of a handled signal.
It's for this scenario that the system call gives EINTR in this case.
We could have libc's sigwait repeat the system call on EINTR.

Unfortunately it is already the case that stop signals cause signal
interruption of system calls when they should be restarted.
rt_sigtimedwait is no different from other system calls in this regard.
It's a general problem.  There is a signal wakeup in order to process the
stop signal.  The blocking system call wakes up diagnoses this with EINTR.
In the case of a handled signal, this gets to the handler setup and the
first thing that does is the SA_RESTART processing.  But when the signal
instead causes a stop (for job control or ptrace) and a later resumption
without running a signal handler, no restart happens.  In the case of the
sleep calls, this causes early wakeups.  In other blocks it produces the
spurious EINTR returns.



Thanks,
Roland