Bug#657835: libc6: libc deadlocks in child process after fork

[Max Dmitrichenko <dmitrmax@gmail.com>]

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