Development/Valgrind

The main documentation is available via module help devel/valgrind on the cluster. Most software modules for applications provide working example batch scripts.

Description	Content
module load devel/valgrind
Availability	bwUniCluster | BwForCluster_Chemistry
License	GPL
Citing	n/a
Links	Valgrind Homepage
Graphical Interface	No

Introduction

Valgrind is an instrumentation framework for building dynamic analysis tools. The main (default) tool memcheck detects a wide variety of memory management bugs. This page introduces the various tools to fetch threading bugs, and profile your programs in detail. As such, any programmer must know valgrind's memcheck. While the Linux distribution provides valgrind, this module comes with a newer version (which may interpret newer instruction sets) and more tools than the system provided one.

Overview

Valgrind ships with various tools, some of them are described in the following table.

Tool	Description
memcheck	Detects heap array over- and underruns, usage of uninitialized memory, memory leaks and incorrect freeing of heap memory.
callgrind	Memory Profiler. Together with kcachegrind allows getting an overview of applications and getting details about memory access and costs.
helgrind	Detects race conditions and deadlocks.
drd	Detects race conditions. Does not detect deadlocks but needs less memory than helgrind.
massif	A heap memory profiler showing the allocation history over time.

Documentation

Online

Online Valgrind Documentation

Local

$ man valgrind

Usage

To simulate your program and gather information about it using a specific tool, valgrind can be called like this

$ valgrind --tool=<tool> --log-file=<logfile> ./example

For example to check for race conditions the command would look like this:

$ valgrind --tool=drd --log-file=log.mem ./example

Beware that the simulation via valgrind can take much longer and can consume much more memory compared to a normal execution. Furthermore the tools can give false positives, i.e. they report errors even though the are none.

Example using drd on OpenMP

The following simple OpenMP-parallel example shows a data race on global data:

#include <stdlib.h>
#include <stdio.h>
#include "omp.h"

int global = 4711;

int main (int argc, char * argv[]) {

    // The following is an ERROR: This should be a (thread-)local variable.
#pragma omp parallel
    global = omp_get_thread_num();

    printf("global:%d\n", global);
    return EXIT_SUCCESS;
}

Compile this example using

$ gcc -Wall -O2 -fopenmp omp_error.c -o omp_error

One may optionally pass the -g to allow Valgrind to print source code lines in the erroneous functions.

Running this example shows:

$ valgrind --tool=drd ./omp_error
...
==1019408== Thread 2:
==1019408== Conflicting store by thread 2 at 0x00601034 size 4
==1019408==    at 0x4006D9: main._omp_fn.0 (openmp_error_access.c:13)
...
==1019408== Allocation context: Data section of /pfs/data5/home/es/es_es/es_rakeller/C/openmp_error_access
==1019408== Other segment start (thread 1)
==1019408==    at 0x4C3F3CF: pthread_create_intercept (drd_pthread_intercepts.c:625)
==1019408==    by 0x4C3F3CF: pthread_create@* (drd_pthread_intercepts.c:631)
==1019408==    by 0x4E84A72: ??? (in /usr/lib64/libgomp.so.1.0.0)
==1019408==    by 0x4E7A6A0: GOMP_parallel (in /usr/lib64/libgomp.so.1.0.0)
==1019408==    by 0x4005C3: main (openmp_error_access.c:9)
==1019408== Other segment end (thread 1)
==1019408==    at 0x4E86FAA: ??? (in /usr/lib64/libgomp.so.1.0.0)
==1019408==    by 0x4E85A1C: ??? (in /usr/lib64/libgomp.so.1.0.0)
==1019408==    by 0x4005C3: main (openmp_error_access.c:9)
==1019408== 
==1019408== Thread 1:
==1019408== Conflicting load by thread 1 at 0x00601034 size 4
==1019408==    at 0x4005C4: main (openmp_error_access.c:15)
==1019408== Allocation context: Data section of /pfs/data5/home/es/es_es/es_rakeller/C/openmp_error_access
==1019408== Other segment start (thread 2)
...

Example for helgrind for PThreads

The following PThread-parallel example demonstrates how to detect data races in parallel programs.

/* pthreads.c */
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <math.h>

#define NUM_THREADS 2

int v = 0;

void* f(void* x)
{
    int j = 0;
    int k = *(int*)x;
    
    for(j = 0; j < 100; j++)
        v += sin(j) + 1 + k;

    return NULL;
}

int main(int argc, char *argv[])
{
    pthread_t threads[NUM_THREADS];
    int idx[NUM_THREADS];
    int t;
   
    for(t=0; t<NUM_THREADS; t++) {
        idx[t] = t;
        pthread_create(&threads[t], NULL, f, (void*)&idx[t]);
    }
    
    for(t=0; t<NUM_THREADS; t++)
        pthread_join(threads[t], NULL);

    printf("%i\n", v);

    pthread_exit(NULL);

    return 0;
}

Compile the program using

$ gcc -Wall -O2 pthreads.c -o pthreads -pthread -lm

where -pthread tells the compiler to link against the Pthreads library and -lm is needed for linking against the math library. This program has a race condition, consecutive executions can give different outputs. Such errors are hard to find because they can show up very rarely. Helgrind can tell you the problematic part of your code:

$ valgrind --tool=helgrind ./pthreads
...
==29237== ----------------------------------------------------------------
==29237== 
==29237== Possible data race during read of size 4 at 0x600C78 by thread #3
==29237== Locks held: none
==29237==    at 0x4007BC: f(void*) (in /pfs/data2/home/xx/xxxx/xxxx/pthreads)
==29237==    by 0x4A0C0D4: mythread_wrapper (hg_intercepts.c:219)
==29237==    by 0x3EDA6079D0: start_thread (in /lib64/libpthread-2.12.so)
==29237==    by 0x3ED9AE8B6C: clone (in /lib64/libc-2.12.so)
==29237== 
==29237== This conflicts with a previous write of size 4 by thread #2
==29237== Locks held: none
==29237==    at 0x4007FB: f(void*) (in /pfs/data2/home/xx/xxxx/xxxx/pthreads)
==29237==    by 0x4A0C0D4: mythread_wrapper (hg_intercepts.c:219)
==29237==    by 0x3EDA6079D0: start_thread (in /lib64/libpthread-2.12.so)
==29237==    by 0x3ED9AE8B6C: clone (in /lib64/libc-2.12.so)
==29237== 
==29237== ----------------------------------------------------------------
...

Now we know that we have to check the function f for a possible data race. A similar output can be achieved using drd with the following command:

$ valgrind --tool=drd ./pthreads

Valgrind can give even better hints when compiled with debug information (helgrind produces similar output):

$ gcc -g -Wall pthreads.c -o pthreads -pthread -lm
$ valgrind --tool=drd ./pthreads
...
==604== Thread 3:
==604== Conflicting load by thread 3 at 0x00600cc0 size 4
==604==    at 0x400749: f(void*) (pthreads.c:17)
==604==    by 0x4A128B4: vgDrd_thread_wrapper (drd_pthread_intercepts.c:355)
==604==    by 0x3EDA6079D0: start_thread (in /lib64/libpthread-2.12.so)
==604==    by 0x3ED9AE8B6C: clone (in /lib64/libc-2.12.so)
==604== Allocation context: BSS section of fs/data2/home/xx/xxxx/xxxx/pthreads
==604== Other segment start (thread 2)
==604==    (thread finished, call stack no longer available)
==604== Other segment end (thread 2)
==604==    (thread finished, call stack no longer available)
...

The execution can take longer but now we know that the problem is most likely in line 17 (which is correct).