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