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|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.

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