This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/20289] Environment locking is not fork-safe
- From: "ranjan.amit8 at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 23 Jun 2016 09:02:41 +0000
- Subject: [Bug malloc/20289] Environment locking is not fork-safe
- Auto-submitted: auto-generated
- References: <bug-20289-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=20289
martin <ranjan.amit8 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from martin <ranjan.amit8 at gmail dot com> ---
Thanks you all for your reply and clarification.
As this is not a bug(deadlock in syslog) but a behavior that conforms to the
specification.
Reference Link:- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454183
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.
--
You are receiving this mail because:
You are on the CC list for the bug.