Messages in this thread | | | Subject | Re: SIGCONT misbehaviour in Linux | Date | Wed, 08 Dec 1999 16:49:48 +0100 | From | Eric Paire <> |
| |
> 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/
| |