> 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()).
Simon-
[ Stormix Technologies Inc. ][ NetNation Communcations Inc. ]
[ sim@stormix.com ][ sim@netnation.com ]
[ Opinions expressed are not necessarily those of my employers. ]
-
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/