[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#454183: marked as done (libc6: deadlock in syslog() after fork)

Your message dated Tue, 10 Nov 2009 15:11:41 +0100
with message-id <20091110141141.GA4766@hall.aurel32.net>
and subject line Re: Bug#454183: libc6: deadlock in syslog() after fork
has caused the Debian Bug report #454183,
regarding libc6: deadlock in syslog() after fork
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
454183: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454183
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6
Version: 2.5-7
Severity: important

the syslog() funktion seems sometimes to end in a deadlock, if a 
multithreaded process, where are threads logging to syslog, at the
same time does a fork() and the child trys to log something to syslog.
the child process hangs in the syslog call. the gdb backtrace is:

#0  0xb7e46b64 in __pthread_sigsuspend (set=0xbf8b7b3c) at
../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c:54
#1  0xb7e45728 in __pthread_wait_for_restart_signal (self=0x806c8c0) at
pthread.c:1224
#2  0xb7e47fe6 in __pthread_alt_lock (lock=0xb7e3bd5c, self=0x806c8c0)
at restart.h:34
#3  0xb7e451dc in *__GI___pthread_mutex_lock (mutex=0xb7e3bd4c) at
mutex.c:123
#4  0xb7d9f8d0 in __tz_convert (timer=0xbf8b7d20, use_localtime=1,
tp=0xbf8b7c98) at tzset.c:570
#5  0xb7d9e00d in __localtime_r (t=0xbf8b7d20, tp=0xbf8b7c98) at
localtime.c:33
#6  0xb7dd98c8 in *__GI_vsyslog (pri=6, fmt=0x8063bae "session:%d -1",
ap=0xbf8b7d58 "\034\003") at ../sysdeps/generic/syslog.c:197
#7  0xb7dd97f2 in *__GI_syslog (pri=6, fmt=0x8063bae "session:%d -1") at
../sysdeps/generic/syslog.c:127

it seems as if the mutex is locked before the fork and not unlocked in
the child.

-- System Information:
Debian Release: lenny/sid
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.3
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

-- no debconf information

--- End Message ---
--- Begin Message --- 
On Wed, Jun 03, 2009 at 09:10:06AM +0200, Damian Pietras wrote:
> Hi,
> 
> I've found this bug doing a research on a similar issue in my program
> and think it's worth to add some information.
> 
> This is not a bug but a behaviour that conforms to the specification:
> 
> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html
> 
> In short: calling any function that is not async-safe (man 7 signal) in
> child process after fork() call in a multi-threaded program has
> undefined behaviour. The problem is with functions (own or system
> library functions) that uses mutexes internally to protect global
> resources. When you call fork at the moment when some mutexes are locked
> you end up with a child that has only one thread and global data that
> were modified in critical sections in other threads at the moment of fork()
> are inconsistent. Also, mutexes are unusable in the child.
> 
> See the above pthread_atfork() description to find out more.
> 

Thanks for the explanation, I guess this bug can be closed now.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: