This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug malloc/20289] Environment locking is not fork-safe


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]