Re: SIGCONT misbehaviour in Linux
Eric Paire (paire@ri.silicomp.fr)
Wed, 08 Dec 1999 16:49:48 +0100
> On Wed, Dec 08, 1999 at 11:14:13AM +0100, Eric PAIRE wrote:
>
> > Hi Linux gurus,
> >
> > Michael Snyder is currently integrating my linuxthreads debugging support
> > inside the source tree of GDB at Cygnus, and he notified what I think is a
> > generic kernel bug in the signal handling:
> >
> > When a process blocked in the kernel receives a stopping signal (POSIX says
> > SIGSTOP, SIGTSTP, SIGTTIN and SIGTTOU), then the process stops, and this is
> > correctly implemented by Linux. *BUT*, when such a process receives a SIGCONT,
> > then it must continue, whatever signal handling is configured in the process.
> >
> > The specific problem here is that, if the process is blocked in
> > sys_nanosleep(), then receiving a SIGSTOP will make it exit from
> > sys_nanosleep() and enter into TASK_STOPPED state in do_signal().
> > When it will be awaken via a SIGCONT, then it will exit immediately
> > from the kernel, whatever time it remains to sleep, even if no signal
> > handler is attached to SIGCONT, which is not the correct POSIX semantics
> > (It should only return if there is a signal handler attached to SIGCONT).
> > Notice also that the remaining time does not take into account the time
> > during which the process has been stopped.
> >
> > The general problem here is that the kernel seems to *ALWAYS* return EINTR
> > when signals have been sent during system calls, *EVEN* when there is no
> > signal handler attached to the signal, which seems to be in contradiction
> > with the generic POSIX semantics of EINTR. I have added the glibc-bug
> > mailing list because I don't know whether the POSIX behaviour should be
> > handled correctly in the libc or in the kernel.
> >
> > BTW, a funny user test to show this misbehaviour is to type the following
> > commands in bash:
> >
> > sleep 1000
> > ^Z
> > fg
> >
> > and the process running sleep 1000 immediatly returns on Linux. I tested it
> > on other systems and it works correctly (the sleep continue).
>
> Hmm...This works properly on libc5 systems, btw. (glibc2.0 and glibc2.1
> use nanosleep(), libc5 uses alarm() and sigsuspend()).
>
This works for the special case of sleep(), which is the example I took,
just because the libc5 sleep implementation looks for the return value;
but what about the other blocking system calls (like nanosleep) ? do they
check properly on EINTR errno that the SIGCONT received signal did have a
signal handling function at the time they received the signal, and restart
automagically the system call that should not have been interrupted ?
This is the reason why my guess is that this feature should be fixed
in the kernel (if Linux is to be POSIX-compliant).
-Eric
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE
Web : http://www.ri.silicomp.com/~paire | Group SILICOMP - Research Institute
Email: eric.paire@ri.silicomp.com | 2, avenue de Vignate
Phone: +33 (0) 476 63 48 71 | F-38610 Gieres
Fax : +33 (0) 476 51 05 32 | FRANCE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/