* ptrace/select/signal errno weirdness
@ 2002-08-15 22:16 Brian Wellington
2002-08-16 4:03 ` Linus Torvalds
0 siblings, 1 reply; 4+ messages in thread
From: Brian Wellington @ 2002-08-15 22:16 UTC (permalink / raw)
To: linux-kernel
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);
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ptrace/select/signal errno weirdness
2002-08-15 22:16 ptrace/select/signal errno weirdness Brian Wellington
@ 2002-08-16 4:03 ` Linus Torvalds
2002-08-16 4:15 ` Brian Wellington
0 siblings, 1 reply; 4+ messages in thread
From: Linus Torvalds @ 2002-08-16 4:03 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ptrace/select/signal errno weirdness
2002-08-16 4:03 ` Linus Torvalds
@ 2002-08-16 4:15 ` Brian Wellington
2002-08-16 5:41 ` Linus Torvalds
0 siblings, 1 reply; 4+ messages in thread
From: Brian Wellington @ 2002-08-16 4:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ptrace/select/signal errno weirdness
2002-08-16 4:15 ` Brian Wellington
@ 2002-08-16 5:41 ` Linus Torvalds
0 siblings, 0 replies; 4+ messages in thread
From: Linus Torvalds @ 2002-08-16 5:41 UTC (permalink / raw)
To: Brian Wellington; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-08-16 5:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-08-15 22:16 ptrace/select/signal errno weirdness Brian Wellington
2002-08-16 4:03 ` Linus Torvalds
2002-08-16 4:15 ` Brian Wellington
2002-08-16 5:41 ` Linus Torvalds
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).