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

Advanced C++ - Stack unwinding

Stack unwinding is normally a concept of removing function entries from call stack (also known as Execution stack, Control stack, Function stack or Run-time stack). Call Stack is a stack data structure that stores active functions' addresses and helps in supporting function call/return mechanism. Every time when a function is called, an entry is made into Call stack which contains the return address of the calling function where the control needs to return after the execution of called function. This entry is called by various names like stack frame , activation frame or activation record. With respect to exception handling , stack Unwinding is a process of linearly searching function call stack to reach exception handler. When an exception occurs, if it is not handled in current function where it is thrown, the function Call Stack is unwound until the control reaches try block and then passes to catch block at the end of try block to handle exception. Also, in this proc...

C++ Multithreading - Race conditions

In the previous C++ Multithreading article I presented you how to pass parameters between threads. Take a detail look on the output of that example once again: In the first line of that output you can notice that output text from two threads is mixed. You are probably wondering why it happens? It is because we are not protecting resources which are shared by two threads (in this example cout stream is shared in both threads) which causes multithreading's phenomenon called race condition . Because threads switching and accessing to shared resources are managed by operating system we do not know when std::cout stream will be accessed by main thread and when it will be accessed by second thread. Therefore in the previous article I mentioned that output of the example can be little different on your computer than my output example. What's more it is possible that this output will be different for few consecutive invoking of the example on the same machine. It is beca...

Advanced C++ - Effective C++ - cheatsheet

I would like to share with you my summary of the "Effective C++" book by Scott Meyers . It is very interesting book for everyone who would like to improve C++ developments skills to be every effective. I highly recommend it. Quick summary of that book, which I prepared you can download after by clicking on below image. Summary of Effective C++ book by Damian Ziobro