Skip to main content

How to quickly investigate memory leak in your application

Every C/C++ software developer meet problem of memory leak (allocating memory over time which is not freed). If you would like to know how to investigate memory leak problem in your application, this article is for you. For memory leak investigation I recommend to use valgrind tool. Especially with it's Massif tool. Let's see the example how we could use that tool for memory leak investigation. Below snippet of code has lots of points where memory leak can occur.
 1 #include <stdio.h>
 2 
 3 void allocmem1()
 4 {
 5     char* memleak2 = malloc(100*sizeof(char));
 6 }
 7 
 8 void allocmem2()
 9 {
10     char* memleak2 = malloc(10*sizeof(char));
11     allocmem1();
12 }
13 
14 void allocmem3()
15 {
16     char* memleak2 = malloc(5*sizeof(char));
17     allocmem2();
18 }
19 
20 int main(int argc, const char **argv)
21 {
22     char* memleak1 = malloc(5*sizeof(char));
23     char* memfreed = malloc(5*sizeof(char));
24 
25     int i=0;
26     for (i=0; i<100; i++){
27       allocmem3();
28     }
29 
30     free(memfreed);
31     return 0;
32 }
33 
34 
First, save above code in main.c file and compile it:
gcc main.c  -o main
Next, examine memory leak occurances using valgrind tool:
valgrind --tool=massif ./a.out
Output of above command should be empty for our example. However, notice that new file has been created in the directory where you invoked valgrind from (massif.out.PID). That file contaisn valgrind data which we will use for our memory leak investigation. Let's make that data human readable. Use ms_print tool for it:
ms_print massif.out.PID
Output of ms_print command allows you to detect where your memory leak are. On the top of that output, you see the graph of memory usage where you can quickly see that we have memory leak. It should look like this one:
 1 
 2     KB
 3 16.45^                                 #
 4      |                                 #
 5      |                                :#
 6      |                                @#
 7      |                                @#
 8      |                                @#
 9      |                               :@#
10      |                               @@#
11      |                               @@#
12      |                              @@@#
13      |                              @@@#
14      |                              @@@#
15      |                             @@@@#
16      |                             @@@@#
17      |                             @@@@#
18      |                            :@@@@#
19      |                            @@@@@#
20      |                            @@@@@#
21      |                           :@@@@@#
22      |                           :@@@@@#
23    0 +--------------------------------->ki
24      0                                                                   143.3
25 
Below, you have reports of which functions, how what amount of memory allocates over time. We have multiple memory leaks in our example. Let's focus on following repeating statement:
 1 
 2 ->58.39% (2,200B) 0x400596: allocmem1 
 3 | ->58.39% (2,200B) 0x4005BC: allocmem2 
 4 |   ->58.39% (2,200B) 0x4005DE: allocmem3 
 5 |     ->58.39% (2,200B) 0x400625: main 
 6 ...
 7 67.82% (3,695B) 
 8 ->58.74% (3,200B) 0x400596: allocmem1 
 9 | ->58.74% (3,200B) 0x4005BC: allocmem2 
10 |   ->58.74% (3,200B) 0x4005DE: allocmem3 
11 ...
12 ->59.15% (6,700B) 0x400596: allocmem1 
13 | ->59.15% (6,700B) 0x4005BC: allocmem2 
14 |   ->59.15% (6,700B) 0x4005DE: allocmem3 
15 |     ->59.15% (6,700B) 0x400625: main 
16 ...
17 ->59.35% (10,000B) 0x400596: allocmem1 
18 | ->59.35% (10,000B) 0x4005BC: allocmem2 
19 |   ->59.35% (10,000B) 0x4005DE: allocmem3 
20 |     ->59.35% (10,000B) 0x400625: main 
That statement contains function which allocates memory (ex. allocmem1) and its caller functions. We can quickly see that memory allocated by fucntion allocmem1 increases with time (2,200B, 3,695B, 6,700B ...). *It indicates memory leak*. Now you can see that for our example we have memory leak in function allocmem1. Try to analyze remaining output statements and deduct where other memory leak exists That's it. Hopefully this quick example shows you how to quickly investigate memory leaks in your application using Valgrind tool. I encourage you to experiment with creating your own memory leak samples and investigateing them using Valgrind _ Massif. More info about valgrind + massif investigation can be found here: Valgrind + Massif Good luck with your memory leak investigation. Picture source: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL3BWmd_5_7HRaYyW_jOdqfJaQtF-IcSeT4pxHFQl-qon2WynXAOFUJ49hQwnHAMkso8bR7kfoGtxPXuuW2LB8uYS9gWOcFSMH8ukH9z6oOrevfN43HcxhtYLnwwc6PIXyGoXw63svNSeN/s640/memoryleak+1.png

Comments

Popular posts from this blog

Blog's new layout

As you noticed this blog has new layout from today. I hope you like it. I think new layout looks better and more modern than previous one. Please, write you opinion about new layout in comments. If you have some ideas how to make this blog better, all ideas are welcomed. Enjoy new layout and blog articles.

QT - foreach algoriithm with const references performance improvement

Today I would like to show you optimal way of using foreach QT algorithm . I will show you why we should pass elements of foreach algorithm by const reference instead of passing them by value. Let me explain it on the below example: Output of this example is: In point I we are creating 3 objects of MyClass class and push them to myClasses QList element. In point II we are using QT foreach algorithm to invoke getValue() method for each object from myClasses list. As you can see on output text for that part of code we are invoking copy constructor before and destructor after invoking getValue() function. It is because we are passing each myClasses list element to foreach algorithm by value. Therefore we are copying that element at the beginning of foreach loop step and removing them (destructing) at the end. This is inefficient solution, especially when class of object being copied is big. It decreases performance. of our application. Solution for that i...

Advanced C++ - Compiler generated functions

When we define some class in our C++ code, compiler is generating some important functions for our class (unless we define it explicitly). Those functions (sometimes called Compiled Generated Functions ) are:  default constructor   destructor   copy constructor   copy assignment operator  During compilation, compiler knows our code and classes usage, so when we are using one of above functions implicitly, it generate that function implicitly for us in the class body. For better explenation, let's see the example below: In point (I) we are defining class TestClass . This class seems to be empty. However we are implicitly using following function in main class:  point III - we are implicitly using defualt constructor in order to create instance of TestClass - default constructor of TestClass is implicitly generated by compiler   point IV - we are using copy constructor of TestClass in order to copy instance to...