Hi, I've found this bug doing a research on a similar issue in my program and think it's worth to add some information.
This is not a bug but a behaviour that conforms to the specification: http://www.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html In short: calling any function that is not async-safe (man 7 signal) in child process after fork() call in a multi-threaded program has undefined behaviour. The problem is with functions (own or system library functions) that uses mutexes internally to protect global resources. When you call fork at the moment when some mutexes are locked you end up with a child that has only one thread and global data that were modified in critical sections in other threads at the moment of fork() are inconsistent. Also, mutexes are unusable in the child. See the above pthread_atfork() description to find out more. -- Damian Pietras http://www.linuxprogrammingblog.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
