Bug#657835: libc6: libc deadlocks in child process after fork
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.
> 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:
This is therefore not a bug in the GNU libc, but rather a bug in your
Aurelien Jarno GPG: 1024D/F1BCDB73