false positives Archer 2.0.0 clang 6.0

[SteffenSeckler]

Context

we are currently using Archer to develop a library for particle simulations:
https://github.com/AutoPas/AutoPas

With archer v1.0.0 no warnings were printed and tests showed that archer worked as it should (it only reported real errors)

We recently tried upgrading from archer v1.0.0 and clang v4.0 to archer v2.0.0 and clang v6.0 and were confronted with a lot of warnings:

Bug

With archer v2.0.0 we get a lot of warnings, mostly in pthread's mutex locking/unlocking see
archerlog.txt

They have the forms:
a) (clearly from the mutexes)

WARNING: ThreadSanitizer: data race (pid=811)
10:   Atomic read of size 1 at 0x7b6800005f40 by main thread:
10:     #0 pthread_mutex_lock ??:? (runTests+0x5a64a7)
...
10:   Previous write of size 1 at 0x7b6800005f40 by thread T8:
10:     #0 pthread_mutex_init ??:? (runTests+0x58f96a)
...
10:   Location is heap block of size 1504 at 0x7b6800005a00 allocated by main thread:
10:     #0 malloc ??:? (runTests+0x5b7d6c)
10:     #1 ___kmp_allocate_align(unsigned long, unsigned long, char const*, int) /ArcherBuild/openmp/build/../runtime/src/kmp_alloc.cpp:1492 (libomp.so+0x205a2)
...
10:   Thread T8 (tid=820, running) created by main thread at:
10:     #0 pthread_create ??:? (runTests+0x58f57b)
10:     #1 __kmp_create_worker /ArcherBuild/openmp/build/../runtime/src/z_Linux_util.cpp:853 (libomp.so+0xc40c9)
...
10: SUMMARY: ThreadSanitizer: data race ??:? in __interceptor_pthread_mutex_lock

or b)

10: WARNING: ThreadSanitizer: data race (pid=811)
10:   Write of size 8 at 0x7b6800005100 by thread T4:
10:     #0 memcpy ??:? (runTests+0x596f1c)
10:     #1 copy_icvs(kmp_internal_control*, kmp_internal_control*) /ArcherBuild/openmp/build/../runtime/src/kmp.h:1794 (libomp.so+0x86593)
...
10:   Previous read of size 8 at 0x7b6800005100 by thread T7:
10:     #0 memcpy ??:? (runTests+0x596f1c)
10:     #1 copy_icvs(kmp_internal_control*, kmp_internal_control*) /ArcherBuild/openmp/build/../runtime/src/kmp.h:1794 (libomp.so+0x86593)
...
10: 
10:   Location is heap block of size 1504 at 0x7b6800004e00 allocated by main thread:
10:     #0 malloc ??:? (runTests+0x5b7d6c)
10:     #1 ___kmp_allocate_align(unsigned long, unsigned long, char const*, int) /ArcherBuild/openmp/build/../runtime/src/kmp_alloc.cpp:1492 (libomp.so+0x205a2)
...
10:   Thread T4 (tid=816, running) created by main thread at:
10:     #0 pthread_create ??:? (runTests+0x58f57b)
10:     #1 __kmp_create_worker /ArcherBuild/openmp/build/../runtime/src/z_Linux_util.cpp:853 (libomp.so+0xc40c9)
...
10: SUMMARY: ThreadSanitizer: data race ??:? in memcpy

Steps to reproduce:

1. Download autopas:

git clone https://github.com/AutoPas/AutoPas.git AutoPas

2. Use our docker image to reproduce the warnings:

cd AutoPas
mkdir build
cd build
docker run -v `pwd`/..:/autopas/ -w /autopas/build/ -it autopas/autopas-build-archer:latest bash -i -c "CXXFLAGS=-Wno-pass-failed CC=clang-archer CXX=clang-archer++ cmake -G Ninja -DCMAKE_BUILD_TYPE=DEBUG -DUSE_VECTORIZATION=OFF .. && ninja -j 4 && ctest --verbose"

Further information

I have tested it with the clang/llvm 6.0 version in ubuntu 16.04 (clang 6.0.0), as well as the latest official release from http://apt.llvm.org/ (also ubuntu 16.04, xenial).

The openmp reposity versions I tested are:

1. release_60 (d5aa29c)
2. latest properly working version from master (b1a95ef, from May 25, 2018), mainly before they started renaming a few things, e.g., ompt_frame_t to omp_frame_t

I only tested the archer master, as the v2.0.0 tag is actually identical to it.

All configurations I tested produced the same warnings.

The dockerfile can be found here:
for v2.0.0:
https://github.com/AutoPas/AutoPas-Dockerfiles/blob/master/buildenv/archer/Dockerfile

for v1.0.0:
https://github.com/AutoPas/AutoPas-Dockerfiles/tree/master/buildenv/archer-v1.0.0

Closing words

I did not yet find the time to just test archer 2.0.0 on an example, so sorry for that.
Help would be appreciated :)

[jprotze]

Please try:
export TSAN_OPTIONS="ignore_noninstrumented_modules=1"

This should remove these reports.

[SteffenSeckler]

Thanks for the quick reply!
This did indeed help.
If this is a known issue, could you document this somewhere?

[dongahn]

Thanks!