Valgrind * is not * a leak check tool

Valgrind * is not * a leak check tool

Summary:

In my community, Valgrind is the most misunderstood tool I know. ValgrindNot just a memory leak detector. It only contains a tool to check for Memory leakage. But what I want to say is that this tool is exactly the smallest component in Valgrind.

Without changing the way Valgrind is called, you can get much more valuable information than most people think. Valgrind will identify potential errors before your program crashes; it will not only tell you where the errors are, but also tell you the reason (in English). Valgrind is firstUnknown BehaviorDetection tool, followed by a function and memory analysis tool, followed by a data competition condition detection tool, and finally a memory leak detection tool.

First and foremost:

To run Valgrind, you only need to switch to the directory where your program is located and run the following command:

Valgrind./myProgram myProgramsFirstArg myProgramsSecondArg

No special parameters are required.

You will also see the output of your program and the debugging output information generated by Valgrind (the rows starting with '= ). If your program includes the-g option (generate debugging Symbol Information) during compilation, Valgrind will provide more help information (for example, the line number of the code to be executed ).

For the purpose of this Article, ignore the content after the "head summary" line in all Valgrind output content. This is what this article does not care about: Content leakage summary.

Usage of Valgrind in Linux

Use Valgrind in Linux for Memory leakage detection and Performance Analysis

Install Ubuntu memory leak detection tool Valgrind

Valgrind-memory debugging and code anatomy tools in Linux

Use Valgrind to discover memory problems in Linux programs [graphic]

What can it detect?

1) Misuse of uninitialized values. This is also its basic skill:

Bool condition;
If (condition ){
// Do the thing
}

Interestingly, most of the time your program just continues to run, and when it comes to running here, there will be no signs of failure. It may (most of the time) seem to be running as you expected. Theoretically, if your program has an error, it should be wrong every time you run the program. These errors are hard and will soon be displayed. You must first determine where an error occurs before fixing it. The problem is that we didn't assign any value to the Boolean variable from the very beginning, and it won't be automatically initialized by the program. at this time, its value may be any random value that happens to stay in its memory location.

In the above example, Valgrind will output such rows:

= 2364 = Conditional jump or move depends on uninitialized value (s)
= 2364 = at 0x400916: main (test. cpp: 106)

Note: The above output shows the cause of unknown behavior caused by the code, not just the location. Even better, Valgrind caught them before these unknown behaviors caused a program crash.

It is difficult to estimate the obvious errors as above, but the following error may not be so good:

Bool condition;
If (foo ){
Condition = true;
}
If (bar ){
Condition = false;
}
If (baz ){
Condition = true;
}
If (condition ){
// Do the thing
}

Here, we only initialize condition in some cases, but not all. Valgrind can still check for undefined behaviors.

Some defensive programming methods can be used to avoid such errors from the root cause. I prefer to give each variable an initial value. Or use the auto keyword to force you to initialize a variable (you cannot deduce the type of the variable without a value ). You can refer to Herb Sutter's blog, which mentions