search

paulfloyd / freebsd_valgrind

Git repo used to Upstream the FreeBSD Port of Valgrind
GNU General Public License v2.0
15 stars 4 forks source link

omp_matinv is failing #186

Closed paulfloyd closed 2 years ago

paulfloyd commented 2 years ago

For a long time.

Some info with a debug build of libomp. Just the first error.

==15219== Conflicting store by thread 1 at 0x049364c0 size 4
==15219==    at 0x48FAB7A: __kmp_allocate_thread (contrib/llvm-project/openmp/runtime/src/kmp_runtime.cpp:4473)
==15219==    by 0x48F584D: __kmp_allocate_team (contrib/llvm-project/openmp/runtime/src/kmp_runtime.cpp:5205)
==15219==    by 0x48F7170: __kmp_fork_call (contrib/llvm-project/openmp/runtime/src/kmp_runtime.cpp:0)
==15219==    by 0x48CA0EC: __kmpc_fork_call (contrib/llvm-project/openmp/runtime/src/kmp_csupport.cpp:308)
==15219==    by 0x2031A1: gj (omp_matinv.c:212)
==15219==    by 0x202A03: invert_matrix (omp_matinv.c:238)
==15219==    by 0x202663: main (omp_matinv.c:327)
==15219== Location 0x49364c0 is 0 bytes inside global var "__kmp_nth"
==15219== declared at contrib/llvm-project/openmp/runtime/src/kmp_global.cpp:440
==15219== Other segment start (thread 2)
==15219==    at 0x4AD654A: thr_new (in /lib/libc.so.7)
==15219==    by 0x494C4A4: pthread_create (in /lib/libthr.so.3)
==15219==    by 0x4855BD5: pthread_create_intercept (drd_pthread_intercepts.c:615)
==15219==    by 0x4855BD5: pthread_create (drd_pthread_intercepts.c:631)
==15219==    by 0x4927738: __kmp_create_worker (contrib/llvm-project/openmp/runtime/src/z_Linux_util.cpp:803)
==15219==    by 0x48FABF6: __kmp_allocate_thread (contrib/llvm-project/openmp/runtime/src/kmp_runtime.cpp:4502)
==15219==    by 0x48F584D: __kmp_allocate_team (contrib/llvm-project/openmp/runtime/src/kmp_runtime.cpp:5205)
==15219==    by 0x48F7170: __kmp_fork_call (contrib/llvm-project/openmp/runtime/src/kmp_runtime.cpp:0)
==15219==    by 0x48CA0EC: __kmpc_fork_call (contrib/llvm-project/openmp/runtime/src/kmp_csupport.cpp:308)
==15219==    by 0x2031A1: gj (omp_matinv.c:212)
==15219==    by 0x202A03: invert_matrix (omp_matinv.c:238)
==15219==    by 0x202663: main (omp_matinv.c:327)
==15219== Other segment end (thread 2)
==15219==    at 0x485843C: pthread_mutex_lock_intercept (drd_pthread_intercepts.c:935)
==15219==    by 0x485843C: pthread_mutex_lock (drd_pthread_intercepts.c:945)
==15219==    by 0x492951C: __kmp_lock_suspend_mx (contrib/llvm-project/openmp/runtime/src/z_Linux_util.cpp:1379)
==15219==    by 0x492951C: __kmp_suspend_template<kmp_flag_64<false, true> > (contrib/llvm-project/openmp/runtime/src/z_Linux_util.cpp:1402)
==15219==    by 0x492951C: void __kmp_suspend_64<false, true>(int, kmp_flag_64<false, true>*) (contrib/llvm-project/openmp/runtime/src/z_Linux_util.cpp:1526)
==15219==    by 0x48C852A: suspend (contrib/llvm-project/openmp/runtime/src/kmp_wait_release.h:906)
==15219==    by 0x48C852A: __kmp_wait_template<kmp_flag_64<false, true>, true, false, true> (contrib/llvm-project/openmp/runtime/src/kmp_wait_release.h:448)
==15219==    by 0x48C852A: kmp_flag_64<false, true>::wait(kmp_info*, int, void*) (contrib/llvm-project/openmp/runtime/src/kmp_wait_release.h:921)
==15219==    by 0x48C48DD: ??? (contrib/llvm-project/openmp/runtime/src/kmp_barrier.cpp:649)
==15219==    by 0x48C7A9F: __kmp_fork_barrier(int, int) (contrib/llvm-project/openmp/runtime/src/kmp_barrier.cpp:1938)
==15219==    by 0x48FB69A: __kmp_launch_thread (contrib/llvm-project/openmp/runtime/src/kmp_runtime.cpp:5814)
==15219==    by 0x4928071: ??? (contrib/llvm-project/openmp/runtime/src/z_Linux_util.cpp:527)
==15219==    by 0x48609F8: vgDrd_thread_wrapper (drd_pthread_intercepts.c:491)
==15219==    by 0x494C82A: ??? (in /lib/libthr.so.3)
==15219==

This just looks like a volatile (i.e., not inherently thread safe) thread counter.

I say that DRD is right and this is a thread hazard.

That might be debug-only.

Another one 

==17255== Thread 15:
--17255-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0x93
==17255== Conflicting load by thread 15 at 0x0561a650 size 4
==17255==    at 0x48C8553: __kmp_wait_template<kmp_flag_64<false, true>, true, false, true> (contrib/llvm-project/openmp/runtime/src/kmp_wai
t_release.h:462)
==17255==    by 0x48C8553: kmp_flag_64<false, true>::wait(kmp_info*, int, void*) (contrib/llvm-project/openmp/runtime/src/kmp_wait_release.h
:921)
==17255==    by 0x48C48DD: ??? (contrib/llvm-project/openmp/runtime/src/kmp_barrier.cpp:649)
==17255==    by 0x48C7A9F: __kmp_fork_barrier(int, int) (contrib/llvm-project/openmp/runtime/src/kmp_barrier.cpp:1938)
==17255==    by 0x48FB69A: __kmp_launch_thread (contrib/llvm-project/openmp/runtime/src/kmp_runtime.cpp:5814)
==17255==    by 0x4928071: ??? (contrib/llvm-project/openmp/runtime/src/z_Linux_util.cpp:527)
==17255==    by 0x48609F8: vgDrd_thread_wrapper (drd_pthread_intercepts.c:491)
==17255==    by 0x494C82A: ??? (in /lib/libthr.so.3)
==17255== Address 0x561a650 is at offset 512 from 0x561a450. Allocation context:
==17255==    at 0x4851584: malloc (vg_replace_malloc.c:385)
==17255==    by 0x48B7FEC: ___kmp_allocate_align (contrib/llvm-project/openmp/runtime/src/kmp_alloc.cpp:1851)
==17255==    by 0x48B7FEC: ___kmp_allocate (contrib/llvm-project/openmp/runtime/src/kmp_alloc.cpp:1903)
==17255==    by 0x48FA999: __kmp_allocate_thread (contrib/llvm-project/openmp/runtime/src/kmp_runtime.cpp:4362)
==17255==    by 0x48F584D: __kmp_allocate_team (contrib/llvm-project/openmp/runtime/src/kmp_runtime.cpp:5205)
==17255==    by 0x48F7170: __kmp_fork_call (contrib/llvm-project/openmp/runtime/src/kmp_runtime.cpp:0)
==17255==    by 0x48CA0EC: __kmpc_fork_call (contrib/llvm-project/openmp/runtime/src/kmp_csupport.cpp:308)
==17255==    by 0x2031A1: gj (omp_matinv.c:212)
==17255==    by 0x202A03: invert_matrix (omp_matinv.c:238)
==17255==    by 0x202663: main (omp_matinv.c:327)
==17255== Other segment start (thread 1)

DRD recognizes pthreadbarrier (and gompbarrier - not sure if they are just aliases?)

There is nothing for kmpbarrier*.

drd/tests/run_opmenmp_test seems quite picky, it requires a libgomp.so with symbols and to have gomp_barrier_init (built with --enable-linux-futex).

paulfloyd commented 2 years ago

I looked at the test script that's supposed to check the libgomp.so exists and has signals. On FreeBSD we just fall off the end (which is a pass). In any case the omp tests for GCC builds succeed, but the script still fails (detects libgomp but no symbols).

paulfloyd commented 2 years ago

I modified drd/tests/run_openmp_test and now these test run with GCC and not clang.

Will revisit if ever anyone asks for OMP support.