[Bug malloc/20289] New: Deadlock issue in glibc-2.23.90

["ranjan.amit8 at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20289

            Bug ID: 20289
           Summary: Deadlock issue in glibc-2.23.90
           Product: glibc
           Version: 2.24
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: malloc
          Assignee: unassigned at sourceware dot org
          Reporter: ranjan.amit8 at gmail dot com
  Target Milestone: ---

Created attachment 9349
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9349&action=edit
test-case(changed-forkenv.c)

Child process in deadlock. 
In the test-case worker thread calls setenv() every 100 microseconds. 
The main thread of this program continues on and forks off children which then
attempt to call unsetenv. It also sets up an alarm handler which will print an
"a" after 1 second. In other words, if 1 second elapsed between that alarm()
call and the exit(), it should print "a". Every time a child gets stuck, you
get another "a".

$ ./x86_64-ran-linux-gcc -Wall -o set-changed-forkenv ../changed-forkenv.c
-lpthread -g

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa^C

Check that out! Lots of alarms are firing off. We're getting stuck!


Below is the backtrace for one of child stuck in deadlock as:

(gdb) bt
#0  0x0000000000400a5f in sigalrm ()
#1  <signal handler called>
#2  0x000000314e8f809c in __lll_lock_wait_private () from /lib64/libc.so.6
#3  0x000000314e835847 in _L_lock_84 () from /lib64/libc.so.6
#4  0x000000314e83525a in unsetenv () from /lib64/libc.so.6
#5  0x0000000000400ab9 in main ()
(gdb)


It's trying to get a lock in glibc within unsetenv(). This never succeeds,
since we're in the child and no thread exists on this side of things to release
that lock. We copied the lock in the "set" state, and there it will stay
forever.





Steps to reproduce:
 Link for Origunal test-case:-
        https://rachelbythebay.com/w/2014/08/16/forkenv/

 Compile the attached test-case:
        $ ./x86_64-ran-linux-gcc -Wall -o set-changed-forkenv
../changed-forkenv.c -lpthread -g
        $ ./set-changed-forkenv
        $ gdb set-changed-forkenv core.7705

        Reading symbols from
/data/home/ramit/WR_LINUX/119-jira/ORIG-WRL43/Cross-build/prefix-glibc24/bin/set-changed-forkenv...done.

warning: core file may not match specified executable file.
[New Thread 7705]
Missing separate debuginfo for
Try: yum --enablerepo='*-debug*' install
/usr/lib/debug/.build-id/eb/ea73f324027016e824c6d0721fa004c9f3a190
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols
found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `./set-changed-forkenv'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000400a5f in sigalrm ()
(gdb) bt
#0  0x0000000000400a5f in sigalrm ()
#1  <signal handler called>
#2  0x000000314e8f809c in __lll_lock_wait_private () from /lib64/libc.so.6
#3  0x000000314e835847 in _L_lock_84 () from /lib64/libc.so.6
#4  0x000000314e83525a in unsetenv () from /lib64/libc.so.6
#5  0x0000000000400ab9 in main ()
(gdb)

-- 
You are receiving this mail because:
You are on the CC list for the bug.