Valgrind Quick Start Guide

Http://www.valgrind.org/docs/manual/quick-start.html:

1. Introduction

Valgrind's toolkit provides a large number of debugging and analysis tools to help you make your program run faster and more correctly. Memcheck is the most popular tool. It can detect many common memory-related errors in C and C ++ programs and may cause crashes and unpredictable behavior errors.

The rest of this Guide provides the minimum information you need to start using the memcheck program to detect memory errors. For complete memcheck and other tools documentation, please read the product manual.

2. Prepare the program

Compile your program with-g to include debugging information, so that the error message of memcheck includes the exact row number. If you can tolerate a slowdown, using-O0 is also a good idea. If-O1 is used, the row number of the error message may be inaccurate, but in general, memcheck works well on the Code Compiled with-O1, in addition, compared with running-O0, the speed is significantly improved. We do not recommend that you use the-O2 or above compilation options, because memcheck occasionally reports Non-initialized value errors that do not actually exist.

3. Run your program under memcheck

If you run the following programs normally:

  myprog arg1 arg2

Use this command line:

  valgrind --leak-check=yes myprog arg1 arg2

Memcheck is the default tool.--leak-checkOption to enable the detailed memory leak detector.

Your program will be much slower than normal operation (such as 20? 30 times), and use more memory. Memcheck reports memory errors and detected leaks.

4. parse memcheck output

The following is an example of a C program named A.C, which contains a memory error and Memory leakage.

  #include <stdlib.h>  void f(void)  {     int* x = malloc(10 * sizeof(int));     x[10] = 0;        // problem 1: heap block overrun  }                    // problem 2: memory leak -- x not freed  int main(void)  {     f();     return 0;  }

Most error messages look like the following description of Problem 1 heap overflow:

  ==19182== Invalid write of size 4  ==19182==    at 0x804838F: f (example.c:6)  ==19182==    by 0x80483AB: main (example.c:11)  ==19182==  Address 0x1BA45050 is 0 bytes after a block of size 40 alloc‘d  ==19182==    at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)  ==19182==    by 0x8048385: f (example.c:5)  ==19182==    by 0x80483AB: main (example.c:11)

Note:

• There is a lot of information about each error message. Read it carefully.
  

• 19182 is the process ID; it is usually not important.
  

• The first line ("invalid write...") tells you what kind of error it is. Here, the program writes some memory that should not be written due to heap block overflow.
  

• Below the first line is a stack trace to tell you where a problem occurs. Stack tracing can become quite large and confusing, especially when you use C ++ STL. They can provide some help from the bottom up. If the stack trace is not large enough, use -- num-callers to make it bigger.
  

• Code addresses (such as 0x804838f) are usually not important, but occasionally critical for tracking weird bugs.
  

• Some error messages have the second part to describe the memory address involved. The above shows that the memory write position is beyond the end of the block allocated by malloc () in row 5th of example. C.

It is worthwhile to modify errors in the order of error reports, because later errors may be caused by previous errors. If you do not do this, this is a common cause of memcheck's difficulty.

The message for Memory leakage is as follows:

  ==19182== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1  ==19182==    at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)  ==19182==    by 0x8048385: f (a.c:5)  ==19182==    by 0x80483AB: main (a.c:11)

Stack tracing tells you where the leaked content exists and is allocated. Sorry, memcheck cannot tell you why the memory is leaked. (Ignore "vg_replace_malloc.c", which is an implementation detail .)

There are several types of leaks; the two most important types are:

• "Definitely lost": Your program's memory is leaking-Fix it!
  

• "Possibly lost": Your program is leaking memory unless you are using pointers to do interesting things (such as moving them to the middle of the heap block ).
  

Memcheck also reports the use of uninitialized values. The most common message is "Conditional jump or move depends on uninitialised value (s )". It is difficult to determine the root cause of these errors. Try to use--track-origins=yesTo obtain additional information. This makes memcheck run slower, but the extra information you get often saves a lot of time figuring out where the uninitialized value comes from.

If you do not understand an error message, please refer to the explanation of error messages from memcheck of valgrind user manual, which contains examples of all error messages generated by memcheck.

5. Notes

Memcheck is imperfect; it sometimes produces false positives and has a mechanism to suppress these false positives (see suppressing errors in the valgrind User Manual ). However, it is usually correct in 99%, so you should be cautious about ignoring the error message. After all, you will not ignore the warning message generated by the compiler, right? If memcheck reports errors in the library code that you cannot change, the suppression mechanism is also useful. The default suppression settings hide many such errors, but you may encounter more.

Memcheck cannot detect every memory error of your program. For example, it cannot detect reading or writing arrays out of the range if these arrays are statically allocated or allocated on the stack. But it can detect many errors that may crash your program (for example, cause a segment error ).

Try to make your program clean and prevent memcheck from reporting any errors. Once you reach this state, when the program changes to make MEMC ?? It is easy to detect problems when heck reports new errors. Past several years of memcheck experience shows that memcheck can even run a huge program without any errors reported. For example, most of Kde, OpenOffice.org, and Firefox are memcheck-clean, or very close.

6. More information

For more information, see valgrind FAQ and valgrind user manual. In addition, other valgrind release tools can be called using the -- tool option.

Valgrind Quick Start Guide