2002-08-15 22:12:54

by Brian Wellington

[permalink] [raw]
Subject: ptrace/select/signal errno weirdness

When sending a SIGINT to a ptraced process (run under gdb), an interrupted
select() call returns with errno==514. linux/include/linux/errno.h says:

/* Should never be seen by user programs */
#define ERESTARTSYS 512
#define ERESTARTNOINTR 513
#define ERESTARTNOHAND 514 /* restart if no handler.. */
#define ENOIOCTLCMD 515 /* No ioctl command */

As gdb is a user program, and the printf is printing it, there's something
wrong. This might be due to a problem in gdb, but the fact that the errno
is being seen in userspace seems bad.

A simple test program is included. To test, build and run it under gdb.
Hit ^C to get back to the gdb prompt, and enter 'signal SIGINT' to send a
SIGINT.

This has been reproduced on 2.4.18 (the Red Hat 7.3 errata kernel) and
2.4.19 (built from scratch).

Brian

----
#include <errno.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <sys/select.h>
#include <sys/signal.h>

void
printsig(int sig) {
fprintf(stderr, "got sig %d\n", sig);
}

int
main(int argc, char **argv) {
int n;
struct sigaction sa;
memset(&sa, 0, sizeof sa);
sa.sa_handler = printsig;
n = sigaction(SIGINT, &sa, NULL);
if (n < 0) {
fprintf(stderr, "sigaction: %s\n", strerror(errno));
exit(1);
}
n = select(0, NULL, NULL, NULL, NULL);
if (n < 0) {
fprintf(stderr, "select: %s\n", strerror(errno));
exit(1);
}
exit(0);
}


2002-08-16 04:00:07

by Linus Torvalds

[permalink] [raw]
Subject: Re: ptrace/select/signal errno weirdness

In article <[email protected]>,
Brian Wellington <[email protected]> wrote:
>When sending a SIGINT to a ptraced process (run under gdb), an interrupted
>select() call returns with errno==514. linux/include/linux/errno.h says:
>
>/* Should never be seen by user programs */
>#define ERESTARTSYS 512
>#define ERESTARTNOINTR 513
>#define ERESTARTNOHAND 514 /* restart if no handler.. */
>#define ENOIOCTLCMD 515 /* No ioctl command */
>
>As gdb is a user program, and the printf is printing it, there's something
>wrong.

No, there's nothing wrong.

The process _itself_ never sees these magic error numbers, because they
are internal to the kernel, and the only time they are seen is by a
tracer that sees them - at the same time as the kernel backed up the
instruction pointer so that the traced process will not actually return
from the system call, it will re-do the system call.

Linus

2002-08-16 04:12:30

by Brian Wellington

[permalink] [raw]
Subject: Re: ptrace/select/signal errno weirdness

On 15 Aug 2002, Linus Torvalds wrote:

> In article <[email protected]>,
> Brian Wellington <[email protected]> wrote:
> >When sending a SIGINT to a ptraced process (run under gdb), an interrupted
> >select() call returns with errno==514. linux/include/linux/errno.h says:
> >
> >/* Should never be seen by user programs */
> >#define ERESTARTSYS 512
> >#define ERESTARTNOINTR 513
> >#define ERESTARTNOHAND 514 /* restart if no handler.. */
> >#define ENOIOCTLCMD 515 /* No ioctl command */
> >
> >As gdb is a user program, and the printf is printing it, there's something
> >wrong.
>
> No, there's nothing wrong.
>
> The process _itself_ never sees these magic error numbers, because they
> are internal to the kernel, and the only time they are seen is by a
> tracer that sees them - at the same time as the kernel backed up the
> instruction pointer so that the traced process will not actually return
> from the system call, it will re-do the system call.

If that's the case, then how does
fprintf(stderr, "select: %s\n", strerror(errno));
print
select: Unknown error 514
?

That's the traced process printing the error, not the tracing process.

Brian

2002-08-16 05:35:12

by Linus Torvalds

[permalink] [raw]
Subject: Re: ptrace/select/signal errno weirdness


On Thu, 15 Aug 2002, Brian Wellington wrote:
>
> If that's the case, then how does
> fprintf(stderr, "select: %s\n", strerror(errno));
> print
> select: Unknown error 514
> ?
>
> That's the traced process printing the error, not the tracing process.

Ahh, dang, there's a patch floating around for this case. Basically,
tracing interferes with the normal behaviour (ie you _shouldn't_ see this
normally, only when tracing system calls).

linus