Overview of the use of Valgrind under Linux __linux

Valgrind Introduction:

Valgrind is the framework of dynamic analysis tools. There are many Valgrind tools that automatically detect many memory management and multiple process/thread bugs, and dissect your program in detail. You can also use the Valgrind framework to implement your own tools.

Valgrind typically includes 6 tools: A Memory error detection tool, two thread error detection tools, cache and branch predictive analysis tools, and heap analysis tools.

The use of Valgrind is related to both the CPU OS and the compiler and C libraries. The following platforms are currently supported:

-X86/linux

-Amd64/linux

-Ppc32/linux

-Ppc64/linux

-Arm/linux

-X86/macosx

-Amd64/macosx

Valgrind is an open-source software under the GNU V2, and you can download the latest source code from http://valgrind.org.

Installation of Valgrind:

1. Download the latest valgrind-3.7.0.tar.bz2d from http://valgrind.org and unzip the package with TAR-XFVALGRIND-3.7.0.TAR.BZ2.

2. Execute./configure, check the configuration of installation requirements.

3. Execute make.

4. Perform make install, preferably with root permissions.

5. Try to valgrind the ls-l to detect whether it is working properly.

Overview of Valgrind:

Valgrind a framework for dynamic analysis tools. It has a series of tools for debugging analysis. The Valgrind architecture is modular, so you can easily add new tools without affecting the current structure.

The following tools are standard configurations at installation time:

Memcheck: Used to detect memory errors. It helps the C and C + + programs to be more correct.

Cachegrind: Used to analyze cache and branch predictions. It helps the program execute faster.

Callgrind: For analysis of function calls.

Helgrind: Used to analyze multithreading.

DRD: Also used to analyze multithreading. Similar to Helgrind, but with different analytical techniques, you can detect different problems.

Massif: for analysis of heaps. It helps the program to streamline the use of memory.

Sgcheck: An experimental tool for detecting stacks and global array overflows, which is complementary to memcheck.

Use of Valgrind:

1. Prepare the procedure:

When the program is compiled with-G, the compiled file contains debug information, and the Memcheck parsing information contains the correct line number. It is best to use the-o0 optimization level, which may be problematic when using-O2 and above optimization levels.

2. Run the program under Memcheck:

If your program is executed as follows:

Myprog arg1 arg2

Then use the following:

Valgrind--leak-check=yes Myprog arg1 arg2

Memcheck is the default tool. --leak-check Open the details of memory leak detection.

Running a program in the above command causes the program to run slowly and consumes a lot of memory. Memcheck will display memory errors and detected memory leaks.

3. How to view the output of Memcheck:

Here is an instance of C code (A.C) with a memory error and a memory leak.

#include <stdlib.h>

void f (void)

{

int*x = (int *) malloc (+ * sizeof (int));

x[10]= 0;

Problem 1:heap Block overrun

}//problem 2:memory Leak--X not freed

int main (void)

{

f ();

Return0;

}

Run as follows:

huerjia@huerjia:~/nfs/valg/test$ Valgrind--leak-check=yes./A

==24780== Memcheck, a memory error detector

==24780== Copyright (C) 2002-2011, and GNUGPL ' d, by Julian Seward et al.

==24780== Using Valgrind-3.7.0 and Libvex;rerun with-h for copyright info

==24780== Command:. A

==24780==

==24780== Invalid Write of size 4

==24780== at 0x80484df:f () (A.c:5)

==24780== by 0x80484f1:main (a.c:11)

==24780== address 0x42d3050 's 0 bytes after a block of size alloc ' d

==24780== at 0x4026444:malloc (vg_replace_malloc.c:263)

==24780== by 0x80484d5:f () (A.c:4)

==24780== by 0x80484f1:main (a.c:11)

==24780==

==24780==

==24780== HEAP SUMMARY:

==24780== in the exit:40 bytes in 1 blocks

==24780== Total heap Usage:1 allocs, 0 frees, Bytes allocated

==24780==

==24780== bytes in 1 blocks aredefinitely lost-loss record 1 of 1

==24780== at 0x4026444:malloc (vg_replace_malloc.c:263)

==24780== by 0x80484d5:f () (A.c:4)

==24780== by 0x80484f1:main (a.c:11)

==24780==

==24780== leak SUMMARY:

==24780== definitely lost:40 bytes in 1 blocks

==24780== indirectly lost:0 bytes in 0 blocks

==24780== possibly lost:0 bytes in 0 blocks

==24780== still reachable:0 bytes in 0 blocks

==24780== suppressed:0 bytes in 0 blocks

==24780==

==24780== for counts of detected andsuppressed errors, rerun with:-V

==24780== ERROR summary:2 errors from 2contexts (suppressed:17 from 6)

How to read this output result:

==24780== Memcheck, a memory error detector

==24780== Copyright (C) 2002-2011, and GNUGPL ' d, by Julian Seward et al.

==24780== Using Valgrind-3.7.0 and Libvex;rerun with-h for copyright info

==24780== Command:. A

This section shows the tools used and version information. 24780 of which is the process ID.

==24780== Invalid Write of size 4

==24780== at 0x80484df:f () (A.c:5)

==24780== by 0x80484f1:main (a.c:11)

==24780== address 0x42d3050 's 0 bytes after a block of size alloc ' d

==24780== at 0x4026444:malloc (vg_replace_malloc.c:263)

==24780== by 0x80484d5:f () (A.c:4)

==24780== by 0x80484f1:main (a.c:11)

This section points out the error: Invalid write. The following lines show the function stack.

==24780== HEAP SUMMARY:

==24780== in the exit:40 bytes in 1 blocks

==24780== Total heap Usage:1 allocs, 0 frees, Bytes allocated

==24780==

==24780== bytes in 1 blocks aredefinitely lost-loss record 1 of 1

==24780== at 0x4026444:malloc (vg_replace_malloc.c:263)

==24780== by 0x80484d5:f () (A.c:4)

==24780== by 0x80484f1:main (a.c:11)

==24780==

==24780== leak SUMMARY:

==24780== definitely lost:40 bytes in 1 blocks

==24780== indirectly lost:0 bytes in 0 blocks

==24780== possibly lost:0 bytes in 0 blocks

==24780== still reachable:0 bytes in 0 blocks

==24780== suppressed:0 bytes in 0 blocks

This section is a summary of the heap and the leak, which can be seen as a memory leak error.

==24780== for counts of detected andsuppressed errors, rerun with:-V

==24780== ERROR summary:2 errors from 2contexts (suppressed:17 from 6)

This section is a summary of all detected errors in the heap. Two errors were detected in the code.

Helgrind: Threading Error Detection Tool

If you use this tool, add--tool=helgrind to the Valgrind command.

Helgrind a thread synchronization error for a program that uses posixpthreads under C,c++.

Helgrind can detect the following three types of errors:

Incorrect use of the 1.POSIX pthreads API

2. Latent deadlock caused by lock and unlock sequence

3. Data race-access to memory without a lock or synchronization mechanism

Take the data race as an example to illustrate the use of Helgrind:

When you do not use a proper lock or other synchronization mechanism to guarantee single-threaded access, two or more threads accessing the same memory may cause data competition.

A simple example of a data race:

#include <pthread.h>

int var = 0;

void* child_fn (void* Arg) {

var++;/* unprotected relative to Parent */* This is line 6/*

Returnnull;

}

int main (void) {

Pthread_tchild;

Pthread_create (&child,null, CHILD_FN, NULL);

var++;/* unprotected relative to the child *//* This is line 13/*

Pthread_join (Child,null);

Return0;

}

Run as follows:

huerjia@huerjia:~/nfs/valg/test$ Valgrind--tool=helgrind./b

==25449== Helgrind, a thread error detector

==25449== Copyright (C) 2007-2011, and GNUGPL ' d, by Openworks LLP et al.

==25449== Using Valgrind-3.7.0 and Libvex;rerun with-h for copyright info

==25449== Command:./b

==25449==

==25449==---thread-announcement------------------------------------------

==25449==

==25449== Thread #1 is the program ' s Rootthread

==25449==

==25449==---thread-announcement------------------------------------------

==25449==

==25449== Thread #2 was created

==25449== at 0x4123a38:clone (in/lib/tls/i686/cmov/libc-2.11.1.so)

==25449== by 0x40430ea:pthread_create@ @GLIBC_2.1 (in/lib/tls/i686/cmov/libpthread-2.11.1.so)

==25449== by 0x402a9ad:pthread_create_wrk (hg_intercepts.c:255)

==25449== by 0x402aa85:pthread_create@* (hg_intercepts.c:286)

==25449== by 0x80484e1:main (b.c:11)

==25449==

==25449==----------------------------------------------------------------

==25449==

==25449== Possible Data Race during read Ofsize 4 at 0x804a020 by thread #1

==25449== Locks Held:none

==25449== at 0x80484e2:main (b.c:12)

==25449==

==25449== This conflicts with a previouswrite of size 4 by thread #2

==25449== Locks Held:none

==25449== at 0X80484A7:CHILD_FN (b.c:6)

==25449== by 0x402ab04:mythread_wrapper (hg_intercepts.c:219)

==25449== by 0x404296d:start_thread (in/lib/tls/i686/cmov/libpthread-2.11.1.so)

==25449== by 0x4123a4d:clone (in/lib/tls/i686/cmov/libc-2.11.1.so)

==25449==

==25449==----------------------------------------------------------------

==25449==

==25449== Possible Data Race during writeof size 4 at 0x804a020 by thread #1

==25449== Locks Held:none

==25449== at 0x80484e2:main (b.c:12)

==25449==

==25449== This conflicts with a previouswrite of size 4 by thread #2

==25449== Locks Held:none

==25449== at 0X80484A7:CHILD_FN (b.c:6)

==25449== by 0x402ab04:mythread_wrapper (hg_intercepts.c:219)

==25449== by 0x404296d:start_thread (in/lib/tls/i686/cmov/libpthread-2.11.1.so)

==25449== by 0x4123a4d:clone (in/lib/tls/i686/cmov/libc-2.11.1.so)

==25449==

==25449==

==25449== for counts of detected andsuppressed errors, rerun with:-V

==25449== use--history-level=approx Or=none to gain increased speed

==25449== the cost of reduced accuracy ofconflicting-access information

==25449== ERROR summary:2 errors from 2contexts (suppressed:0 from 0)

Error message from "Possible data race during write of size 4 at 0x804a020 by thread #1

"At the beginning, you can see the address and size of the race access and the stack information of the call."

The second call stack from "This conflicts with a previous write of size 4 by thread #2

"Start, which indicates that there is a race between this and the first call stack.

Once you've found two call stacks, how do you find the root cause of the race State:

The code is first checked by each call stack, and they all show access to the same location or variable.

Now consider how to correct this to make multithreaded access secure:

1. Use locks or other synchronization mechanisms to ensure that only independent access is available at the same time.

2. Use methods such as conditional variables to determine the order of multiple accesses.

This paper introduces the architecture of Valgrind, and emphatically introduces its most widely used tools: Memcheck and Helgrind. The basic use methods of Memcheck and Helgrind are expounded. Early discovery of memory issues and multiple process synchronization issues in a project can greatly improve development efficiency, and Valgrind is an excellent tool to help you achieve this goal.