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

[Aurelien Jarno <aurelien@aurel32.net>]

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.

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