| Summary: | It appears syslog can go into deadlock when it receives a signal where the signal handler also syslogs | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Brett Lomas <b.lomas> |
| Component: | libc | Assignee: | Roland McGrath <roland> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | glibc-bugs |
| Priority: | P2 | Flags: | fweimer:
security-
|
| Version: | 2.3.4 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Project(s) to access: | ssh public key: | ||
| Bug Depends on: | |||
| Bug Blocks: | 724 | ||
This problem is avoided by changes already in the trunk CVS, though not yet in the 2.3 branch. Subject: Bug 671 CVSROOT: /cvs/glibc Module name: libc Branch: glibc-2_3-branch Changes by: roland@sources.redhat.com 2005-02-16 11:00:09 Added files: sysdeps/generic: syslog.c Log message: 2005-02-02 Alfred M. Szmidt <ams@gnu.org> [BZ #671] * sysdeps/generic/syslog.c (send_flags) [!send_flags]: Define it. 2005-01-25 Roland McGrath <roland@redhat.com> [BZ #671] * sysdeps/generic/syslog.c [NO_SIGPIPE]: Protect sigpipe_handler decl. 2005-01-24 Ulrich Drepper <drepper@redhat.com> [BZ #671] * misc/syslog.c: Moved to... * sysdeps/generic/syslog.c: ...here. [NO_SIGIPE]: Don't install SIGPIPE handler. * sysdeps/unix/sysv/linux/syslog.c: New file. * sysdeps/unix/sysv/linux/kernel-features.h: Define __ASSUME_MSG_NOSIGNAL. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/generic/syslog.c.diff?cvsroot=glibc&only_with_tag=glibc-2_3-branch&r1=NONE&r2=1.3.4.1 Subject: Bug 671 CVSROOT: /cvs/glibc Module name: libc Branch: glibc-2_3-branch Changes by: roland@sources.redhat.com 2005-02-16 11:00:16 Added files: sysdeps/unix/sysv/linux: syslog.c Removed files: misc : syslog.c Log message: 2005-01-24 Ulrich Drepper <drepper@redhat.com> [BZ #671] * misc/syslog.c: Moved to... * sysdeps/generic/syslog.c: ...here. [NO_SIGIPE]: Don't install SIGPIPE handler. * sysdeps/unix/sysv/linux/syslog.c: New file. * sysdeps/unix/sysv/linux/kernel-features.h: Define __ASSUME_MSG_NOSIGNAL. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/misc/syslog.c.diff?cvsroot=glibc&only_with_tag=glibc-2_3-branch&r1=1.44&r2=NONE http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/syslog.c.diff?cvsroot=glibc&only_with_tag=glibc-2_3-branch&r1=NONE&r2=1.1.4.1 Subject: Bug 671 CVSROOT: /cvs/glibc Module name: libc Branch: glibc-2_3-branch Changes by: roland@sources.redhat.com 2005-02-16 11:00:22 Modified files: sysdeps/unix/sysv/linux: kernel-features.h Log message: 2005-01-26 Ulrich Drepper <drepper@redhat.com> [BZ #671] * sysdeps/unix/sysv/linux/kernel-features.h: Found reference to MSG_NOSIGNAL being in 2.2 kernels. 2005-01-24 Ulrich Drepper <drepper@redhat.com> [BZ #671] * misc/syslog.c: Moved to... * sysdeps/generic/syslog.c: ...here. [NO_SIGIPE]: Don't install SIGPIPE handler. * sysdeps/unix/sysv/linux/syslog.c: New file. * sysdeps/unix/sysv/linux/kernel-features.h: Define __ASSUME_MSG_NOSIGNAL. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/kernel-features.h.diff?cvsroot=glibc&only_with_tag=glibc-2_3-branch&r1=1.81&r2=1.81.2.1 These changes are in the 2.3 branch as well as the trunk now. |
I had a program which seemed unresponsive. So I attached GDB to it and got the following stack strace: #0 0x00a7e579 in __lll_mutex_lock_wait () from /lib/tls/libc.so.6 #1 0x00a6d955 in _L_mutex_lock_328 () from /lib/tls/libc.so.6 #2 0x093979f8 in ?? () #3 0x0805322f in _IO_stdin_used () #4 0xbfff90cc in ?? () #5 0xbfff9064 in ?? () #6 0x00ac79a0 in map () from /lib/tls/libc.so.6 #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x00000000 in ?? () #10 0xbfff8f04 in ?? () #11 0x00000000 in ?? () #12 0x00000000 in ?? () #13 0x0000006e in ?? () #14 0x00000014 in ?? () #15 0x00000001 in ?? () #16 0x09397c88 in ?? () #17 0x00000000 in ?? () #18 0x41e9970f in ?? () #19 0x09397c88 in ?? () #20 0x0000003d in ?? () #21 0x00a6d8f0 in sigpipe_handler () from /lib/tls/libc.so.6 #22 0x00a6ceef in syslog () from /lib/tls/libc.so.6 #23 0x0804d519 in pusherchld (sig=17) at pusher.c:212 #24 <signal handler called> #25 0x00a71e8a in send () from /lib/tls/libc.so.6 #26 0x00a6d2a2 in vsyslog () from /lib/tls/libc.so.6 #27 0x00a6ceef in syslog () from /lib/tls/libc.so.6 #28 0x0804d8ef in pusherparent (ppipe=5, gconf=0x9395890) at pusher.c:355 #29 0x0804a821 in main (ac=1024, av=0x1) at daemon.c:465 It appears that while syslog was attempting to send it got a SIGCHLD signal, which also syslogs. I have a trivial program (below) which reproduces the problem more often than not with the follow stack trace: #0 0x0042be09 in __lll_mutex_lock_wait () from /lib/tls/libc.so.6 #1 0x0041b1b5 in _L_mutex_lock_328 () from /lib/tls/libc.so.6 #2 0x09eaa008 in ?? () #3 0x08048808 in _IO_stdin_used () #4 0xbfffb258 in ?? () #5 0xbfffb1f4 in ?? () #6 0x004743a0 in map () from /lib/tls/libc.so.6 #7 0x00000000 in ?? () The program is: #include <stdio.h> #include <syslog.h> #include <stdlib.h> #include <signal.h> void sigchldHandler(int sig) { syslog(LOG_INFO,"Child %d died!!\n",getpid()); } #define SLEEP_MAX 20.0 void child() { int usecsleep; srand(time(NULL)+getpid()); usecsleep=1+(int) (SLEEP_MAX*rand()/(RAND_MAX+1.0)); usleep(usecsleep); } #define CHILDREN 50 #define NUM_SYSLOGS 1000 int main(int argc,char **argv) { pid_t pids[CHILDREN]; int i; signal(SIGCHLD,sigchldHandler); for(i=0;i<CHILDREN;i++) { switch((pids[i]=fork())) { case 0: child(); exit(0); case -1: fprintf(stderr,"Failed fork\n"); exit(1); } } for(i=0;i<NUM_SYSLOGS;i++) syslog(LOG_INFO,"parent: hello!"); for(i=0;i<CHILDREN;i++) waitpid(pids[i],NULL,0); return 0; } Thanks