ptrace/select/signal errno weirdness

ptrace/select/signal errno weirdness

[Brian Wellington]

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);
}

Re: ptrace/select/signal errno weirdness

[Linus Torvalds]

In article <Pine.LNX.4.44.0208151508060.21876-100000@spratly.nominum.com>,
Brian Wellington  <bwelling@xbill.org> 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

Re: ptrace/select/signal errno weirdness

[Brian Wellington]

On 15 Aug 2002, Linus Torvalds wrote:

> In article <Pine.LNX.4.44.0208151508060.21876-100000@spratly.nominum.com>,
> Brian Wellington  <bwelling@xbill.org> 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

Re: ptrace/select/signal errno weirdness

[Linus Torvalds]

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