Linux Memory Leak Detection Tool Valgrind Introduction

Currently, an application that analyzes real-time traffic is developed in Linux, and a memory leak is found in the program during a joint test.

This is anxious, will soon be on-line, fortunately found a valgrind tool, the perfect solution to the problem of memory leaks.

Recommend you can use to see.

Valgrind is a set of simulation-based program debugging and analysis tools running on Linux, and its main author is Julian Seward, who won the Google-o ' Reilly Open Source Award, which contains a kernel-a software-synthesized CPU, and a series of gadgets Each tool can perform a task-commissioning, analysis, or testing. Valgrind can detect memory leaks and memory violations, and can analyze the use of the cache, and so on, flexible and powerful, can be straight through the wrong heart, it is the programmer's Swiss Army knife.

(i). Valgrind Overview
Valgrind generally includes the following tools:
1.Memcheck (later we only introduce this memory detection tool)
The most common tool used to detect memory problems in the program, all memory reads and writes are detected, and all calls to malloc ()/free ()/new/delete are captured. Therefore, it can detect the following problems:
1. Use of uninitialized memory;
2. Read/write the memory block after release;
3. Read/write memory blocks that exceed malloc allocations;
4. Read/write inappropriate memory blocks in the stack;
5. Memory leaks, pointers to a piece of memory are lost forever;
6. Incorrect malloc/free or new/delete matching;
The DST and src pointers overlap in the 7,memcpy () correlation function.
These problems are often the most vexing problem for C + + programmers, and Memcheck is very helpful here.
2.Callgrind
and Gprof similar analysis tools, but it to the operation of the program observation is more nuanced, can provide us with more information. Unlike gprof, it does not require additional special options when compiling source code, but it is recommended to add debugging options. Callgrind collects some data from the program runtime, establishes a function call graph, and optionally carries out a cache simulation. At the end of the run, it writes the parsing data to a file. Callgrind_annotate can convert the contents of this file into a readable form.
3.Cachegrind
The cache parser, which simulates the first-level cache i1,dl and level two caches in the CPU, can pinpoint the loss and hit of the cache in the program. It can also provide us with the number of cache misses, memory references, and each line of code, each function, each module, and the entire program, if needed. This is a great help in optimizing the program.
4.Helgrind
It is primarily used to check for competition issues that occur in multithreaded programs. Helgrind looks for areas in memory that are accessed by multiple threads without a consistent lock, which are often places where threads are out of sync and can cause hard-to-dig errors. Helgrind implements a competitive detection algorithm called "Eraser", and makes further improvements to reduce the number of reported errors. However, Helgrind is still in the experimental stage.
5. Massif
The stack analyzer, which measures how much memory the program uses in the stack, tells us the size of heap blocks, heap management blocks, and stacks. Massif can help us reduce memory usage, and in modern systems with virtual memory, it can also speed up the operation of our programs and reduce the chances of the program staying in the swap area.
In addition, Lackey and Nulgrind are also available. Lackey is a small tool, seldom used; Nulgrind just shows developers how to create a tool. We will not do the introduction.

(b). Valgrind Download and install

1. Download:

Valgrind official website: http://valgrind.org download

If you have SVN installed, you can download the latest version directly: SVN co svn://svn.valgrind.org/valgrind/trunk valgrind

2. Installation

CD Valgrind

./autogen.sh

./configure--prefix= ...

Make

Make install

(b). Memory analysis using the Memcheck tool

1. Compile the debug version of your program./testmem

2, execution: Valgrind--tool=memcheck--leak-check=full--log-file=./log.txt./testmem

3. Wait patiently and analyze the results (the Log.txt results file contains the code that causes the memory leak in the source location, which is the red part of the following illustration)

To illustrate:

The following is a problematic C program code TEST.C

#include <stdlib.h>
void f (void)
{
int* x = malloc (* sizeof (int));
X[10] = 0; Issue 1: Array subscript out of bounds
}//Issue 2: Memory not released
int main (void)
{
f ();
return 0;
}
1. Compile the program test.c
Gcc-wall test.c-g-O test
2. Use Valgrind to check program bug
Valgrind--tool=memcheck--leak-check=full./test
3, Analysis output debugging information
==3908== Memcheck, a memory error detector.
==3908== Copyright (C) 2002-2007, and GNU GPL ' d, by Julian Seward et al.
==3908== Using Libvex Rev 1732, a library for dynamic binary translation.
==3908== Copyright (C) 2004-2007, and GNU GPL ' d, by Openworks LLP.
==3908== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==3908== Copyright (C) 2000-2007, and GNU GPL ' d, by Julian Seward et al.
==3908== for more details, rerun with:-V
==3908==
--3908--DWARF2 CFI reader:unhandled CFI instruction 0:50
--3908--DWARF2 CFI reader:unhandled CFI instruction 0:50
/* array out of bounds error */
==3908== Invalid Write of size 4
==3908== at 0x8048384:f (test.c:6)
==3908== by 0x80483ac:main (test.c:11)
==3908== Address 0x400c050 is 0 bytes after a block of size alloc ' d
==3908== at 0x40046f2:malloc (vg_replace_malloc.c:149)
==3908== by 0x8048377:f (Test.c:5)
==3908== by 0x80483ac:main (test.c:11)
==3908==
==3908== ERROR summary:1 errors from 1 contexts (suppressed:14 from 1)
==3908== malloc/free:in use at exit:40 bytes in 1 blocks.
==3908== Malloc/free:1 Allocs, 0 frees, bytes allocated.
==3908== for counts of detected errors, rerun with:-V
==3908== searching for pointers to 1 not-freed blocks.
==3908== checked 59,124 bytes.
==3908==
==3908==
/* There is no memory space released */
==3908== bytes in 1 blocks is definitely lost in loss record 1 of 1
==3908== at 0x40046f2:malloc (vg_replace_malloc.c:149)
==3908== by 0x8048377:f (Test.c:5)
==3908== by 0x80483ac:main (test.c:11)
==3908==
==3908== LEAK SUMMARY:
==3908== definitely lost:40 bytes in 1 blocks.
==3908== possibly lost:0 bytes in 0 blocks.
==3908== still reachable:0 bytes in 0 blocks.
==3908== suppressed:0 bytes in 0 blocks.

Description of the memory Leak Detection tool Valgrind under Linux