Valgrind is a collection of tools to check the correctness of a program. The main tool in it is memcheck. It reports memory leak, out of bound writes, improperly initialized variables etc. This provides a report which pin points the correct location of the error. So this is a good tool to debug programs with unpredictable behavior and crash.
Using
Inorder to see the exact line number of error, compile the code with -g option and reports could be misleading if optimization above level 1 are used(-O1). The -g option compiles the code with debugging symbols enabled, this helps valgrind to locate line number.
Use this program prog.c
prog.c
-------
void fun()
{
char *a = (char *)malloc(10 * sizeof(char));
a[10] = 'a';
}
main()
{
fun();
return 0;
}
prog.c has two major errors,
1. a[10] = ‘a’;
a[10] is out of the allocated region. Writing to this region could produce mysterious behavior. This is called heap block overrun.
2. 10 byte block pointed by a is never freed. So on return to main, that block remains inaccessible and unusable. This is a serious memory leak.
Lets use valgrind to detect these errors,
Compile the code with -g option
$ cc -g prog.c
Generate report
$ valgrind –leak-check=yes ./a.out
can use 2>&1 to redirect report to a file( $ valgrind –leak-check=yes ./a.out > report 2>&1 )
Analyzing report
Various error messages and summaries can be found. error messages are generated in case of out of bound writes, here a[10].
The corresponding report is
==4836== Invalid write of size 4
==4836== at 0x80483FF: fun(prog.c:6)
==4836== by 0x8048411: main (prog.c:11)
==4836== Address 0x419a050 is 0 bytes after a block of size 40 alloc’d
==4836== at 0x4024F20: malloc (vg_replace_malloc.c:236)
==4836== by 0x80483F5: fun(prog.c:5)
==4836== by 0x8048411: main (prog.c:11)
4836 is the process id. First line shows, error is due to an invalid write of size 4. Below it is a complete stack trace. The error happened at line 6 of prog.c. Read stack trace from bottom to up. Started from main, then a function call to fun, malloc and error at last. Error shows the address we tried to write is beyond the allocated 40 byte block. This information is quite useful to make the code correct.
The Leak summery show the memory leaks.
Here,
==4836== LEAK SUMMARY:
==4836== definitely lost: 40 bytes in 1 blocks
==4836== indirectly lost: 0 bytes in 0 blocks
==4836== possibly lost: 0 bytes in 0 blocks
==4836== still reachable: 0 bytes in 0 blocks
==4836== suppressed: 0 bytes in 0 blocks
Second line shows the 40 byte block lost in function fun. Report includes other types of leaks also.
Valgrind checks these errors and leaks in runtime like a virtual machine executing each instruction of a code. So it is time consuming for large code. But the report generated is very much useful and can be used to correct mistakes which are otherwise very difficult to detect.
@shijitht 