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 08:09:33 +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|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #3 from martin <ranjan.amit8 at gmail dot com> ---
(In reply to Andreas Schwab from comment #1)
> setenv and unsetenv are not thread safe.
Thanks for reply.
Agreed setenv and unsetenv are not thread safe.
Here The setenv() internally calls for __add_to_environ () from
/lib64/libc.so.6 which calls alloca() and allocate memory which acquires mutex
lock internally.
Now after fork when child process calls malloc and waits until it acquire the
lock, which finally not going to happen. That is why deadlock occur.
Now I modified the test-case with "syslog(), which as per list is thread safe :
http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_01
Still I am stuck in deadlock.
(gdb) bt
#0 0x0000000000400aaf in sigalrm ()
#1 <signal handler called>
#2 0x000000314e8f809c in __lll_lock_wait_private () from /lib64/libc.so.6
#3 0x000000314e8e5148 in _L_lock_798 () from /lib64/libc.so.6
#4 0x000000314e8e4c12 in __vsyslog_chk () from /lib64/libc.so.6
#5 0x000000314e8e50d0 in syslog () from /lib64/libc.so.6
#6 0x0000000000400b2b in main ()
--
You are receiving this mail because:
You are on the CC list for the bug.