lkml.org 
[lkml]   [1999]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: SIGCONT misbehaviour in Linux
    Date
    From
    > 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/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:2.929 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site