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

Bug#657835: marked as done (libc6: libc deadlocks in child process after fork)

Your message dated Thu, 2 Feb 2012 16:44:15 +0100
with message-id <20120202154415.GE2817@hall.aurel32.net>
and subject line Re: Bug#657835: libc6: libc deadlocks in child process after fork
has caused the Debian Bug report #657835,
regarding libc6: libc deadlocks in child process 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.)


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

One thread of multithreaded application calls fork(). According to the POSIX
standard only that thread which called fork() would present in the child
process. But the state of all mutexes, condvars and other objects are copied
into the child process "as is" and should be reinitialized.

A call for gmtime_r() from the user applications will lock internal libc lock
__tzset_lock (defined in time/tzset.c). If one thread was calling gmtime_r()
while another thread was calling fork(), this lock is copied into the child
process in the locked state. So the first call of the child process for
gmtime_r() will deadlock it. Apparently fork() implementation should have reset
the state of all internal mutexes in the child process before returning control
to it.

This bug still applies to the head revision of glibc and eglibc. May be there
are other places inside of libc which are subject to the same behaviour.


-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin                      2.11.3-2   Embedded GNU C Library: Binaries
ii  libgcc1                       1:4.4.5-8  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]         1.5.36.1   Debian configuration management sy
ii  glibc-doc                     2.11.3-2   Embedded GNU C Library: Documentat
ii  locales                       2.11.3-2   Embedded GNU C Library: National L

-- debconf information excluded

--- End Message ---
--- Begin Message --- 
On Sun, Jan 29, 2012 at 01:52:15PM +0100, Aurelien Jarno wrote:
> On Sun, Jan 29, 2012 at 02:09:06PM +0400, Max Dmitrichenko wrote:
> > Package: libc6
> > Version: 2.11.3-2
> > Severity: important
> > 
> > One thread of multithreaded application calls fork(). According to the POSIX
> > standard only that thread which called fork() would present in the child
> > process. But the state of all mutexes, condvars and other objects are copied
> > into the child process "as is" and should be reinitialized.
> 
> True.
> 
> > A call for gmtime_r() from the user applications will lock internal libc lock
> > __tzset_lock (defined in time/tzset.c). If one thread was calling gmtime_r()
> > while another thread was calling fork(), this lock is copied into the child
> > process in the locked state. So the first call of the child process for
> > gmtime_r() will deadlock it. Apparently fork() implementation should have reset
> > the state of all internal mutexes in the child process before returning control
> > to it.
> > 
> 
> gmtime_r() is not an async-signal-safe function, and therefore should
> not be called after a fork in a multithreaded application.
> 
> For more details, see:
> http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html
> 
> This is therefore not a bug in the GNU libc, but rather a bug in your
> program.
> 

As explained, it's not a bug in the GNU libc, I am therefore closing
this bug.

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

--- End Message ---
Reply to: