Valgrind (Helgrind) false positives?

Question

Here is a simple parallel fortran program which clearly has no threading errors.

  program example
    implicit none
    !$OMP PARALLEL
    !$OMP END PARALLEL
  end program

I compile it with gfortran example_parallel.f90 -fopenmp -g. I then run it with valgrind with valgrind --tool=helgrind ./a.out. Part of the result is show below:

==43721== Helgrind, a thread error detector
==43721== Copyright (C) 2007-2017, and GNU GPL'd, by OpenWorks LLP et al.
==43721== Using Valgrind-3.17.0.GIT-lbmacos and LibVEX; rerun with -h for copyright info
==43721== Command: ./a.out
==43721== 
==43721== ---Thread-Announcement------------------------------------------
==43721== 
==43721== Thread #2 was created
==43721==    at 0x1009D1DC6: __bsdthread_create (in /usr/lib/system/libsystem_kernel.dylib)
==43721==    by 0x100A33DF3: _pthread_create (in /usr/lib/system/libsystem_pthread.dylib)
==43721==    by 0x1004705D1: gomp_team_start (in /usr/local/Cellar/gcc/10.2.0/lib/gcc/10/libgomp.1.dylib)
==43721==    by 0x100468BCC: GOMP_parallel (in /usr/local/Cellar/gcc/10.2.0/lib/gcc/10/libgomp.1.dylib)
==43721== 
==43721== ---Thread-Announcement------------------------------------------
==43721== 
==43721== Thread #1 is the program's root thread
==43721== 
==43721== ----------------------------------------------------------------
==43721== 
==43721== Possible data race during read of size 8 at 0x104914638 by thread #2
==43721== Locks held: none
==43721==    at 0x10046FED8: gomp_thread_start (in /usr/local/Cellar/gcc/10.2.0/lib/gcc/10/libgomp.1.dylib)
==43721==    by 0x100C3124F: ???
==43721==    by 0x70000C0ABFFF: ???
==43721==    by 0x70000C0ABFDF: ???
==43721==    by 0x70000C0ABFFF: ???
==43721==    by 0x70000C0ABFCF: ???
==43721== 
==43721== This conflicts with a previous write of size 8 by thread #1
==43721== Locks held: none
==43721==    at 0x100A33DFE: _pthread_create (in /usr/lib/system/libsystem_pthread.dylib)
==43721==    by 0x1004705D1: gomp_team_start (in /usr/local/Cellar/gcc/10.2.0/lib/gcc/10/libgomp.1.dylib)
==43721==    by 0x100468BCC: GOMP_parallel (in /usr/local/Cellar/gcc/10.2.0/lib/gcc/10/libgomp.1.dylib)
==43721==  Address 0x104914638 is on thread #1's stack

[... Lots more errors below I just skip to the end]

--43721:0:schedule VG_(sema_down): read returned -4
==43721== 
==43721== Use --history-level=approx or =none to gain increased speed, at
==43721== the cost of reduced accuracy of conflicting-access information
==43721== For lists of detected and suppressed errors, rerun with: -s
==43721== ERROR SUMMARY: 35 errors from 32 contexts (suppressed: 0 from 0)

Are these 35 errors false positives? If not, what am I doing wrong? I'm using MacOS 10.15.7, valgrind installed with homebrew following this post.

libgomp is known for generating false positives. You need a tool that is OpenMP-aware, such as Intel Inspector. — Hristo Iliev, Jan 05 '21 at 10:31

score 0 · Answer 1 · answered Jan 11 '21 at 18:21

As @Hristolliev pointed out, libgomp is not compatible with Helgrind, and is known to generate false positives. I found the following on the Valgrind manual:

Runtime support library for GNU OpenMP (part of GCC), at least for GCC versions 4.2 and 4.3. The GNU OpenMP runtime library (libgomp.so) constructs its own synchronisation primitives using combinations of atomic memory instructions and the futex syscall, which causes total chaos since in Helgrind since it cannot "see" those.

Fortunately, this can be solved using a configuration-time option (for GCC). Rebuild GCC from source, and configure using --disable-linux-futex. This makes libgomp.so use the standard POSIX threading primitives instead. Note that this was tested using GCC 4.2.3 and has not been re-tested using more recent GCC versions. We would appreciate hearing about any successes or failures with more recent versions.

Valgrind (Helgrind) false positives?

1 Answers1