[llvm-bugs] [Bug 26199] New: PowerPC Potential Deadlock with omp_set_lock

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26199

            Bug ID: 26199
           Summary: PowerPC Potential Deadlock with omp_set_lock
           Product: OpenMP
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Runtime Library
          Assignee: unassignedbugs at nondot.org
          Reporter: matt.davis at pgroup.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 15660
  --> https://llvm.org/bugs/attachment.cgi?id=15660&action=edit
Runtime deadlock

Hello,

I think that I might have found a potential trigger for deadlock within the
kmpc runtime.  I can successfully recreate this in linux on an OpenPOWER
machine, using both the Intel version of the omp runtime and the one provided
at openmp.llvm.org via svn.
Intel: libomp_20151009_oss.tgz, and built using 'make compiler=gcc'.
LLVM: http://llvm.org/svn/llvm-project/openmp/trunk with revision: r257078
built using cmake and only setting the cc and cxx cmake macros.

This test case calls an omp_set_lock/omp_unset_lock in the body of a 'parallel
for'.  When running with around 6 threads, the test will occasionally
(frequently but not consistently) get stuck: in calling kmpc_set_lock and the
other calling kmpc_unset_lock.  Both of the aforementioned threads are stuck in
kmp_wait_yield_4.  Since I cannot get this sample to trigger consistently, I do
have success wrapping the executable in a shell for-loop:  
for i in `seq 200`; do ./a.out; done

System: Linux 3.16.0-44-generic #59~14.04.1-Ubuntu SMP Tue Jul 7 15:08:52 UTC
2015 ppc64le ppc64le ppc64le GNU/Linux

Debugger Dump:
(gdb) info threads
  Id   Target Id         Frame 
  7    Thread 0x3fff7b18f1a0 (LWP 129534) "a.out" 0x00003fff7b43eb74 in
__pthread_cond_timedwait (cond=0x3fff7b51d180 <__kmp_wait_cv>,
mutex=0x3fff7b51d100 <__kmp_wait_mx>, abstime=0x3fff7b18e600) at
pthread_cond_timedwait.c:199
  6    Thread 0x3fff7b15f2a0 (LWP 129535) "a.out" 0x00003fff7b43e6f0 in
__pthread_cond_wait (cond=0x10039585b00, mutex=0x10039585b80) at
pthread_cond_wait.c:187
  5    Thread 0x3fff7b04f3a0 (LWP 129536) "a.out" 0x00003fff7b43e6f0 in
__pthread_cond_wait (cond=0x10039588e80, mutex=0x10039588f00) at
pthread_cond_wait.c:187
  4    Thread 0x3fff7af3f4a0 (LWP 129537) "a.out" 0x00003fff7b4f238c in
__kmp_wait_yield_4 () from libomp.so
  3    Thread 0x3fff7ae2f5a0 (LWP 129538) "a.out" 0x00003fff7b43e6f0 in
__pthread_cond_wait (cond=0x1003958f600, mutex=0x1003958f680) at
pthread_cond_wait.c:187
  2    Thread 0x3fff7ad1f6a0 (LWP 129539) "a.out" 0x00003fff7b4f2354 in
__kmp_wait_yield_4 () from libomp.so
* 1    Thread 0x3fff7b524850 (LWP 129533) "a.out" 0x00003fff7b43e6f0 in
__pthread_cond_wait (cond=0x10039582c80, mutex=0x10039582d00) at
pthread_cond_wait.c:187

Thread 2:
#0  0x00003fff7b4f2354 in __kmp_wait_yield_4 () from libomp.so
#1  0x00003fff7b4f3584 in __kmp_release_queuing_lock () from libomp.so
#2  0x00003fff7b4f3084 in __kmp_unset_indirect_lock(unsigned int*, int) () from
libomp.so
#3  0x00003fff7b4af178 in __kmpc_unset_lock () from libomp.so
#4  0x00003fff7b4deef4 in omp_unset_lock at OMP_3.0 () from libomp.so

Thread 4:
#0  0x00003fff7b4f238c in __kmp_wait_yield_4 () from libomp.so
#1  0x00003fff7b4f7040 in __kmp_acquire_queuing_lock () from libomp.so
#2  0x00003fff7b4f2ff4 in __kmp_set_indirect_lock(unsigned int*, int) () from
libomp.so
#3  0x00003fff7b4af098 in __kmpc_set_lock () from libomp.so
#4  0x00003fff7b4dee34 in omp_set_lock at OMP_3.0 () from libomp.so

I hope that my attached sample will provide you with enough information to help
diagnose this.  If not, please let me know.

-Matt

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160118/c3644614/attachment.html>