| ||||||||||||||||||||||||||||||||||||||||
|
Home |
Forum |
MAN Pages |
Tutorials | Directory |
HOWTOs |
About Me | Contact You are Browsing Linux HOWTOS |
||||||||||||||||||||||||||||||||||||||||
 |
4. A Closer View4.1. Why Valgrind?As said above, memory management is prone to errors that are too hard to detect. Common errors may be listed as:
These errors usually lead to crashes. This is a situation where we need Valgrind. Valgrind works directly with the executables, with no need to recompile, relink or modify the program to be checked. Valgrind decides whether the program should be modified to avoid memory leak, and also points out the spots of "leak." Valgrind simulates every single instruction your program executes. For this reason, Valgrind finds errors not only in your application but also in all supporting dynamically-linked (.so-format) libraries, including the GNU C library, the X client libraries, Qt if you work with KDE, and so on. That often includes libraries, for example the GNU C library, which may contain memory access violations. 4.2. Usage4.2.1. Invoking ValgrindThe checking may be performed by simply placing the word valgrind just before the normal command used to invoke the program. For example:
Valgrind provides thousands of options. We deliberately avoid them, not to make this article boring. The output contains the usual output of ps -ax also with the detailed report by valgrind. Any error (memory related) is pointed out in the error report. 4.2.2. How to Identify the Error from the Error ReportConsider the output of Valgrind for some test program:
Here, 1353 is the process ID. This part of the error report says that a read error has occurred at line number 7, in the function print. The function print is called by function main, and both are in the file valg_eg.c. The function main is called by the function __libc_start_main at line number 129, in ../sysdeps/generic/libc-start.c. The function __libc_start_main is called by free@@GLIBC_2.0 in the file /home/deepu/valg/a.out. Similarly details of calling malloc are also given. 4.2.3. Types of Errors with ExamplesValgrind can only really detect two types of errors: use of illegal address and use of undefined values. Nevertheless, this is enough to discover all sorts of memory management problems in a program. Some common errors are given below. 4.2.3.1. Use of uninitialized memorySources of uninitialized data are:
This is not a problem with calloc since it initializes each allocated bytes with 0. The new operator in C++ is similar to malloc. Fields of the created object will be uninitialized. Sample program:
Here the value of p is uninitialized, therefore p may contain some random value (garbage), so an error may occur at the condition check. An uninitialized variable will cause error in 2 situations:
4.2.3.2. Illegal read/writeIllegal read/write errors occurs when you try to read/write from/to an address that is not in the address range of your program. Sample program:
Here you are trying to read/write from/to address (p+sizeof(int)*11) which is not allocated to the program. 4.2.3.3. Invalid freeValgrind keeps track of blocks allocated to your program with malloc/new. So it can easily check whether argument to free/delete is valid or not. Sample program:
Valgrind checks the address, which is given as argument to free. If it is an address that has already been freed you will be told that the free is invalid. 4.2.3.4. Mismatched Use of FunctionsIn C++ you can allocate and free memory using more than one function, but the following rules must be followed:
Sample program:
Output by valgrind is:
>From the above "ERROR SUMMARY" it is clear that there is 0 bytes in 0 blocks in use at exit, which means that the malloc'd have been freed by delete. Therefore this is not a problem in Linux, but this program may crash on some other platform. 4.2.3.5. Errors Occur Due to Invalid System Call ParameterValgrind checks all parameters to system calls. Sample program:
Here, buf = p contains the address of a 10 byte block. The read system call tries to read 100 bytes from standard input and place it at p. But the bytes after the first 10 are unaddressable. 4.2.3.6. Memory Leak DetectionConsider the following program:
In the above program p contains the address of a 20-byte block. But it is not freed anywhere in the program. So the pointer to this 20 byte block is lost forever. This is known as memory leaking. We can get the leak summary by using the Valgrind option --leak-check=yes. 4.2.4. How to Suppress ErrorsValgrind detects numerous problems in many programs which come pre-installed on your GNU/Linux system. You can't easily fix these, but you don't want to see these errors (and yes, there are many!). So Valgrind reads a list of errors to suppress at startup, from a suppression file ending in .supp. Suppression files may be modified. This is useful if part of your project contains errors you can't or don't want to fix, yet you don't want to continuously be reminded of them. The format of the file is as follows.
You can then run the program with:
4.3. Limitations and Dependencies of Valgrind.No software is free from limitations. The same is the case of Valgrind, however most programs work fine. The limitations are listed below.
Valgrind is closely tied to details of the CPU, operating system and to a less extent, compiler and basic C libraries. Presently Valgrind works only on the Linux platform (kernels 2.2.X or 2.4.X) on x86s. Glibc 2.1.X or 2.2.X is also required for Valgrind. |
|
||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||
