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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
