1

I test a simple helloword on my mac under C++ with the opnemp library, via terminal using the following two commandes:

/usr/local/bin/clang++-omp -fopenmp helloworld.cpp -o test
/usr/local/bin/valgrind  --tool=helgrind --log-file=a.log ./test

The output is correct:

warning: no debug symbols in executable (-arch x86_64)
Hello World from thread = 0
Hello World from thread = 1
Hello World from thread = 3
Hello World from thread = 2
Number of threads = 4

but the log file (a.log) contains: "174986 errors from 231 contexts"(as error summary)

Here's a part of the log file:

==643== ---Thread-Announcement------------------------------------------
==643== 
==643== Thread #1 is the program's root thread
==643== 
==643== ----------------------------------------------------------------
==643== 
==643== Possible data race during read of size 4 at 0x10057C118 by thread #3
==643== Locks held: none
==643==    at 0x10055D1F4: spin_lock (in /usr/lib/system/libsystem_platform.dylib)
==643==    by 0x10057092D: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==643==    by 0x10056E384: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==643== 
==643== This conflicts with a previous write of size 4 by thread #1
==643== Locks held: none
==643==    at 0x10055D200: spin_unlock (in /usr/lib/system/libsystem_platform.dylib)
==643==    by 0x1000434B0: __kmp_create_worker (in /usr/local/Cellar/libiomp/20150701/lib/libiomp5.dylib)
==643==    by 0x100031E3D: __kmp_allocate_thread (in /usr/local/Cellar/libiomp/20150701/lib/libiomp5.dylib)
==643==    by 0x10002E7A1: __kmp_allocate_team (in /usr/local/Cellar/libiomp/20150701/lib/libiomp5.dylib)
==643==    by 0x10002FA2D: __kmp_fork_call (in /usr/local/Cellar/libiomp/20150701/lib/libiomp5.dylib)
==643==    by 0x100027F0D: __kmpc_fork_call (in /usr/local/Cellar/libiomp/20150701/lib/libiomp5.dylib)
==643==    by 0x100000CE8: main (in ./test)
==643==  Address 0x10057c118 is in the Data segment of /usr/lib/system/libsystem_pthread.dylib

The code of the "helloworld" is:

#include <stdio.h>
#include <libiomp/omp.h>
#include <stdlib.h>
int main (int argc, char *argv[]) {   
int nthreads=4, tid;
#pragma omp parallel num_threads(nthreads) private(tid)
 {

    //Obtain thread number
    tid = omp_get_thread_num();
    printf("Hello World from thread = %d\n", tid);

    // Only master thread does this
    if (tid == 0)
    {
        printf("Number of threads = %d\n", nthreads);
    }

 } 
return 0;
}

Does anyone have an idea of these errors (data race)? I do not have a shared data between these threads.

Cecile
  • 93
  • 10
  • It is most definitely a false positive. `libiomp` implements its own synchronisation primitives that Valgrind is not able to recognise properly as such. Locks are, after all, implemented using unprotected but very well controlled on hardware level access to shared variables. – Hristo Iliev Jan 31 '17 at 21:43

1 Answers1

2

This is most likely a false positive. See for example a similar discussion for the same issue with libgomp. It could also be an actual problem in the libiomp / pthread implementation, but that seems rather unlikely.

There seems to be little that you can do about. In general, if the top of the stack is in a library, it is either a false positive or bug in the library, or you are misusing it (e.g. running memcpy on a buffer from multipl threads).

If your binary is at the top of the stack, it is more clearly an issue with your code.

Your code is fine wrt. to data races.

Zulan
  • 21,896
  • 6
  • 49
  • 109