__kernel_vsyscall () hangs in SIGCHLD handler - Kernel

This is a discussion on __kernel_vsyscall () hangs in SIGCHLD handler - Kernel ; Is there some reason that syslog() sleeps in __kernel_vsyscall() when invoked from a signal handler? Is it that I am not allowed to call any system calls from inside a signal handler? I use syslog() from a daemon client/server sys. ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: __kernel_vsyscall () hangs in SIGCHLD handler

  1. __kernel_vsyscall () hangs in SIGCHLD handler

    Is there some reason that syslog() sleeps in __kernel_vsyscall() when
    invoked from a signal handler? Is it that I am not allowed to call any
    system calls from inside a signal handler?

    I use syslog() from a daemon client/server sys. app. that (tries) to log
    whenever a child exits. I've registered a sigChld handler via
    sigaction(using SA_SIGINFO semantics), and everything works fine and is
    fully functional, including calls to syslog() in the normal program
    flow. However, if I try to use syslog() from inside the signal handler
    itself, it never returns.

    Tracing the program with gdb, I get:

    Attaching to program: lfsad, process 8845
    `system-supplied DSO at 0xffffe000' has disappeared; keeping its
    symbols.
    [Thread debugging using libthread_db enabled]
    [New Thread -1211890000 (LWP 8845)]
    Loaded symbols for /usr/lib/libxml2.so.2
    Loaded symbols for /lib/libz.so.1
    Loaded symbols for /lib/libm.so.6
    Loaded symbols for /lib/librt.so.1
    Loaded symbols for /lib/libc.so.6
    Loaded symbols for /lib/libdl.so.2
    Loaded symbols for /lib/ld-linux.so.2
    Loaded symbols for /lib/libpthread.so.0
    Reading symbols from /lib/libnss_files.so.2...done.
    Loaded symbols for /lib/libnss_files.so.2
    0xffffe410 in __kernel_vsyscall ()
    (gdb) bt
    #0 0xffffe410 in __kernel_vsyscall ()
    #1 0xb7d2457e in __lll_mutex_lock_wait () from /lib/libc.so.6
    #2 0xb7d14d6d in _L_mutex_lock_621 () from /lib/libc.so.6
    #3 0x08511b18 in ?? ()
    #4 0xbf86b64d in ?? ()
    #5 0xbf86b628 in ?? ()
    #6 0xbf86b578 in ?? ()
    #7 0xb7d76320 in ?? () from /lib/libc.so.6
    #8 0xfbad8001 in ?? ()
    #9 0x00000014 in ?? ()
    #10 0x00000000 in ?? ()

    If I check its status in /proc/8845/status, I see that its sleeping. If
    I remove the call to syslog() in the signal handler, everything is
    fine, no sleeping, and the rest of the syslog() work fine.

    Am I doing something wrong?

    Thanks,
    John

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: __kernel_vsyscall () hangs in SIGCHLD handler

    On 9/26/07, John Z. Bohach wrote:
    > Is there some reason that syslog() sleeps in __kernel_vsyscall() when
    > invoked from a signal handler?


    Only very few functions are allowed to be called from signal handlers.
    This is clearly spelled out in the POSIX spec. Section XSH 2.4.3
    lists the allowed functions. syslog of course is not on it.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: __kernel_vsyscall () hangs in SIGCHLD handler

    On Wednesday 26 September 2007 10:03:33 Ulrich Drepper wrote:
    > On 9/26/07, John Z. Bohach wrote:
    > > Is there some reason that syslog() sleeps in __kernel_vsyscall()
    > > when invoked from a signal handler?

    >
    > Only very few functions are allowed to be called from signal
    > handlers. This is clearly spelled out in the POSIX spec. Section XSH
    > 2.4.3 lists the allowed functions. syslog of course is not on it. -
    > To unsubscribe from this list: send the line "unsubscribe
    > linux-kernel" in the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/


    Thank you for this information...also thanks to Giacomo who answered me
    offline...

    --john
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: __kernel_vsyscall () hangs in SIGCHLD handler

    Ulrich Drepper writes:
    > On 9/26/07, John Z. Bohach wrote:
    > > Is there some reason that syslog() sleeps in __kernel_vsyscall() when
    > > invoked from a signal handler?

    >
    > Only very few functions are allowed to be called from signal handlers.
    > This is clearly spelled out in the POSIX spec. Section XSH 2.4.3
    > lists the allowed functions. syslog of course is not on it.


    The Linux kernel itself imposes no restrictions on what you can
    do in user-space signal handlers.

    However, user-space is a different story. The interrupted thread
    may have held a lock, in which case calling code from the signal
    handler that tries to take the same lock may result in a deadlock.
    Or the thread may be been in the process of updating some private
    data, in which case calling code from the signal handler that tries
    to access that data may result in data corruption. And then there's
    libc which may wrap your signal handler with code doing unspecified
    libc magic. And so on, the possibilities for failure are endless :-)
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread