See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/355759855

Memory Leak Detection Tools: A Comparative Analysis

Conference Paper · August 2021

DOI: 10.1109/RTEICT52294.2021.9574012

CITATION READS

1 1,173

2 authors:

Dilip Gangwar Avita Katal

Indraprastha Institute of Information Technology University of Petroleum & Energy Studies
1 PUBLICATION 1 CITATION 77 PUBLICATIONS 1,590 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Avita Katal on 23 August 2022.

The user has requested enhancement of the downloaded file.

 2021 6th International Conference on Recent Trends on Electronics, Information, Communication & Technology (RTEICT), August 27th & 28th 2021

Memory Leak Detection Tools: A Comparative

Analysis
2021 International Conference on Recent Trends on Electronics, Information, Communication & Technology (RTEICT) | 978-1-6654-3559-8/21/$31.00 ©2021 IEEE | DOI: 10.1109/RTEICT52294.2021.9574012

Dilip Kumar Gangwar Avita Katal

Department of Computer Science and Department of Virtualization
Engineering University of Petroleum and Energy
Graphic Era Hill University Studies
Dehradun, India Dehradun, India
[email protected] [email protected]

Abstract— Memory leak is a situation when the memory The languages like C, C++ lack automatic garbage
taken up by dynamically allocated objects is not deallocated collection mechanisms, whereas Java, .Net have such
after its use. Memory leak is a serious problem in embedded mechanisms. Garbage collection mechanism can avoid
systems as they are memory constrained devices. This can also memory leak issues. But there are performance problems
be a serious problem in servers as continuous leaking of with such garbage collection mechanisms too. It is very
memory space results in denial of client requests in due time. costly to run garbage collection on the server in the middle of
The programmer has to take care while writing the code of the the client request [2]. Moreover, manual inspection and
application for such main memory related issues. Apart from careful writing of code remains the need many times.
manual inspection of the code for memory leak, finding illegal
memory issues can be tedious sometimes. Various tools are Over a period of time, there are several tools and libraries
available in order to detect main memory related issues in the developed targeted for different operating systems to tackle
software which can ease the testing time of application. These the issue of memory leak. The tools can be categorized as (a)
tools are categorized as static and dynamic analysis tools. Static Analysis Tools (b) Dynamic Analysis Tools. Static
These tools help programmers to write memory safe and clean analysis is the testing of the application without executing the
code without going into memory leak and related issues. This application itself. Dynamic analysis tests the application by
paper discusses different memory leakage detection tools. The running the application. Both types of tools have their
paper also provides the comparison of different tools on the importance. The static analysis examines all execution paths
basis of different parameters and concludes with the evaluation
and not only those invoked during execution. Dynamic
of the memory detection tools on the basis of time taken. The
results show that Mtrace tool takes maximum time for analysis
analysis can find the vulnerabilities which are too complex to
and Electric fence tools takes minimum time for analysis. be found out by static analysis. This paper discusses four
popular dynamic analysis tools which can detect the memory
Keywords— Memory leak detection, Dynamic memory leak in the applications. Some of these tools don't even need
management, Memory deallocation, Memory leak detection tools the source code of the application for their working.

I. INTRODUCTION The tools can help developers enhance their productivity

and facilitate the reliability of their applications by efficiently
The software or the applications written for practical use identifying threading and memory issues that might arise
should be user friendly. At the same time, they must be early in the development process, helping programmers to
robust with increasing workload and should not interfere with develop more reliable applications.
the other applications. Along with writing the clean code, the
programmer must focus on the issues like memory leak, CPU The main challenge faced during memory leak detection
utilization by the application and segmentation faults. with tools is the slowness of the tool i.e. performance issues.
Memory leak is a type of resource leak which occurs when The Memcheck tool inside the Valgrind tool is based on the
the resource’s deallocation is not performed correctly in the shadow value concept. Also, as the code size and complexity
application code. A memory leak can also happen if an object of the software increases, a practical memory leak detector
stored in the memory cannot be accessed by the running code needs to be highly scalable capable of checking millions of
in any condition. The resource no longer used is not freed lines of code within minutes. Third main challenge which
properly in the code by the programmer leading to several comes up in designing of these memory leak checking tools
problems. The unused object which is no longer needed and is accuracy. The false positive cases reported by tools for
not freed yet can result in over consumption of memory detecting leaks can make them unusable. Lastly, as memory
leading to denial of service to other clients or applications. leak detection tools & processes can make heavy use of the
Reduced available memory leads to increased response time architecture of the operating system and low level details,
and poor performance by the system. Memory leak may not many tools can be made only as per specific architecture/OS.
be an issue with large memory systems, but memory related This paper is organized as shown in Fig 1: Section II
issues become a severe concern in memory constrained discusses the related work. Section III discusses various
devices like embedded systems [1]. The other applications memory leak detector tools. Section IV compares these tools
where the memory is allocated for each continuing task like with respect to different parameters. Section V discusses the
rendering the frames on screen for a video can raise a big future work followed by conclusion in section VI.
concern for memory leak. Some of the other memory related
errors include double free, accessing invalid memory
locations, reading uninitialized memory, using freed memory
etc.

978-1-6654-3559-8/21/$31.00 ©2021 IEEE

315

Authorized licensed use limited to: University of Petroleum & Energy Studies. Downloaded on August 23,2022 at 18:12:47 UTC from IEEE Xplore. Restrictions apply.
 Cachegrind, Callgrind, Massif and Helgrind. The most
popular of these tools is Memcheck. It can detect many
memory-related errors that are common in C and C++
programs and that can lead to crashes and unpredictable
behavior. It also helps in finding synchronization related
errors in multithreading programs and analysis of memory
consumption.
Several tools in Valgrind:

Memcheck:
Fig 1: Organization of Sections in this Paper It is a dynamic analysis tool. Basically, it can detect the
II. RELATED WORK following memory related problems including memory leak:
1. The use of uninitialized memory.
The authors in [3] have presented a projection-based 2. Read/write the released memory block.
method for detecting memory leaks in C programming with 3. Read/write beyond the memory block allocated by
complicated control flows. The suggested technique malloc.
minimizes the analysis complexity by projecting the original
4. Read/write inappropriate memory blocks in the stack.
control flow graph of a program to a simplified one, based on
the properties of memory allocation and deallocation in C 5. Memory leak, the pointer to a piece of memory is lost
source code. forever.
6. Incorrect malloc/free or new/delete matching.
The authors in [4] have presented SMOKE, a phased 7. Overlapping problem of the destination and source
method to resolve memory leak methods. Instead of applying pointers in the memcpy().
a uniform precise analysis for all pathways in the first stage,
they utilize a scalable but imprecise analysis to calculate a Cachegrind:
concise collection of possible memory leak paths. They use a It can tell the cache misses and hits in the program which
more detailed analysis in the second step to validate the can help to optimize the program.
viability of those candidates.
The authors in [5] have suggested a technique for Callgrind:
investigating the utility of static analysis tools in detecting It helps to detect the function call sequence in a
various types of memory leaks. They begin by categorizing program’s run and makes the call return graph.
memory leak vulnerabilities into 11 categories based on heap
memory patterns and software architecture. Massif:
The authors in [6] demonstrate a dynamic method to It is a heap analyzer, which tells the amount of heap
identify, eliminate, and repair memory leaks. A program to memory used by the program. It tells the useful space and
be examined is instrumented before execution using their extra bytes allocated for alignment and book-keeping
method. Dynamic symbolic execution is used to expose purposes. It can also show the stack memory used by the
memory breaches across all execution pathways. When program (not the default behavior). The profiling data
relevant statements are run during program execution, collected by this tool is written to a file.
information about each allocated memory region is updated.
Helgrind:
The authors in [7] have proposed a unique hybrid
automatic memory leak detection technique for soft real-time It is a tool to detect thread synchronization related errors.
embedded system software. To overcome their unique It basically detects 3 types of errors: misuse of POSIX
constraints, the methodology blends static and dynamic pthreads API, deadlock and data race problems.
techniques. With the aid of source code annotation and
control flow graphs, the static phase provides possible Fig. 2 shows the code which suffers from memory leak
memory leak alerts. The dynamic phase entails simulating issue. Inside the function f(), malloc() allocates the dynamic
abstracted memory behavior using data from an abstract memory on heap and the reference to that memory is saved
memory model (AMM). inside pointer x. But the programmer forgets to deallocate
that memory after use, leading to the main memory space
Most of the work done in memory leakage detection
leak issue.
includes different techniques proposed for detecting memory
leakage. None of the literature as per our knowledge
discusses about the various memory leakage detection tools
available. In this paper, a brief introduction to such tools is
given. Also, the tools discussed are compared based on
various parameters.
III. MEMORY LEAK DETECTION TOOLS
A. Valgrind
The Valgrind [8] tool is a collection of a number of Fig 2: Code having Memory leak issue
debugging and profiling tools that helps to find the heap When memcheck tool is run on code shown in Fig. 2, the
memory, memory leak issues, incorrect use of malloc/free or memory leak issue observed is as shown in Fig. 3
new/delete in C, C++. It contains tools like Memcheck,

316

Authorized licensed use limited to: University of Petroleum & Energy Studies. Downloaded on August 23,2022 at 18:12:47 UTC from IEEE Xplore. Restrictions apply.
 to link to. It is capable of detecting overruns of memory
allocated on a heap as well as memory accesses that have
already been released.
After linking the code shown in Fig. 7 with an electric fence
library, we get the output as shown in Fig. 8. It captures the
segmentation fault using gdb.

Fig 3: Memory Leak detected after running memcheck tool

There are 2 solutions to avoid memory leak in this code:

(1) Use free() before the end of f(), which will deallocate the
dynamically allocated memory by malloc() as shown in Fig.
4.

Fig 7: Code in which invalid memory is being accessed. x[11]=50 will lead
to segmentation fault

Fig 4: Using free() inside called function to avoid memory leak

If the function f() is made to return the pointer x, then the

caller function main can also free the allocated memory on
heap as shown in Fig 5.
Fig 8: Segmentation fault is generated after linking code shown in Fig. 6
with electric fence and running with gdb.

Electric fence tool actually adds extra memory (fence)

before and after the allocated memory. If the program tries
to access that memory (fence), segmentation fault is raised.
It stops on the very first instruction where the segmentation
fault is observed in code.

C. Mtrace
Mtrace [10] is a memory debugging tool included in the
GNU C library. It helps to detect memory leaks. The source
Fig 5: Using free() inside caller function to avoid memory leak
code needs to be modified to detect memory leak with
Fig 6 shows that there is no memory leak after using the mtrace. As shown in Fig 9, the code suffers from memory
free(). leak issues as the allocated memory is not deallocated after
use.

Fig 6: Memory leak issue is resolved after fixing the code

B. Electric fence
Electric fence [9] is a memory-debugging tool, which is Fig 9: Code instrumented with mtrace() and muntrace().
implemented in the form of a library that our program needs

317

Authorized licensed use limited to: University of Petroleum & Energy Studies. Downloaded on August 23,2022 at 18:12:47 UTC from IEEE Xplore. Restrictions apply.
 The function mtrace installs handlers for malloc, realloc When the code is analyzed using Deleaker (used as a
and free; the function muntrace disables these handlers. The plugin inside Microsoft Visual Studio 2019), the memory
output is written to a file mentioned by the environment leak problems were reported at line 6 and 7 as shown in Fig
variable MALLOC_TRACE. It can be clearly seen that the 13. The hit count shows the count of allocations made at the
memory leak of 4 bytes after we check the trace file using same place in application/code. As memory allocation has
mtrace as shown in Fig 10. been done 5 times in for loop with the same pointer variable
x, so the Fig 14 shows the hit count value as 5.

Fig 10: Demo to show the memory leak issue in the code shown in Fig. 9

After freeing the memory pointed by p using free(p) as

shown in Fig. 11, mtrace run on this code.

Fig 14: The inspection of code shows that there is memory leak observed
after we inspect the code shown in Fig. 13 with visual studio using
Deleaker Memory Leak detection tool.

If the memory pointed by pointer x and y is freed by

free() as shown in Fig 15, then the memory leak problem is
resolved as shown in Fig. 16. (No memory leak is observed)

Fig 11: The memory pointed by p is freed by free(p).

Fig. 12 shows that no memory leak is detected after

running mtrace on code shown in Fig. 11

Fig 12: No memory leak is observed after running mtrace on the code
shown in Fig. 11

D. Deleaker
Deleaker [11] is a memory profiling tool, which supports
languages like C++, C#, .Net and Delphi. This tool can
either Fig 15: Code having memory leak issues in line 6 and line 7
run as a standalone application or be integrated with many
IDEs like Microsoft Visual Studio, Delphi, C++ Builder,
and Qt Creator. We have integrated Deleaker with Visual
Studio 2019 to perform our experiments. It finds leaks
related to memory and handles. This tool can detect GDI
(Graphics Device Interface) leaks which can hamper the
performance of applications in windows OS. Deleaker is
supported on Windows only.
Fig 13 shows the code which has allocated memory on heap
in line 6 and line 7. The code suffers from memory leak as
the memory locations pointed by the pointers x and y are not
deallocated.
Fig 16: No memory leak is observed when Deleaker is run
on Fig. 15
IV. COMPARISON OF TOOLS AND EVALUATION
A. Comparison
Table 1 shows the comparison of various Memory
leakage detection Tools based on different parameters.
Fig 13: Code having memory leak issues in line 6 and line 7

318

Authorized licensed use limited to: University of Petroleum & Energy Studies. Downloaded on August 23,2022 at 18:12:47 UTC from IEEE Xplore. Restrictions apply.
 Table 1: Comparison of Memory debugging tools based on various parameters

Line Number by
Single Threaded

Source code for

Issues analyzed
Need to modify

error detection
Multithreaded
Application or

Tells the exact

OS supported

Thread Safe
Support for

Application
Languages
Supported

default
Tools

Valgrind Linux, C, C++, Java, Multithreaded No Yes Yes Memory leak, double
Solaris, Perl, Python, Application free, uninitialised
Android assembly memory, read/write
code, Fortran, memory after malloc(),
Ada and many incorrect freeing of
others. heap memory,
mismatched use of
malloc/new/new[]
versus
free/delete/delete[]

Electric Linux C, C++ Multithreaded No No No overruns of memory

fence Application (using allocated on a heap,
GDB issues with memory
only) already freed

Mtrace Linux C, C++ Single Threaded Yes Yes No memory leaks caused
Application by unbalanced calls to
the malloc() and free()
function

Deleaker Windows C++, C#, Multithreaded No Yes Yes Memory leak, GDI
.Net, Delphi Application leak, Handle leak, Leak
caused by COM

B. Evaluation of Performance Table 2 shows the time taken by each tool to analyze or
detect the memory related issues.
The time taken by each tool is evaluated to report its
analysis on the code shown in Fig 17. Table 2: Time taken by each tool to perform the memory debugging

Name of the Tool Time taken to do

analysis by tool (in
seconds)

Valgrind 0.533

Electric fence 0.393

Mtrace 28.902

Deleaker 0.713

Fig 17: Code for Evaluation of time taken by different tools It can be observed from Table 2 that the Mtrace tool
takes maximum time for analysis. This is because much
time is taken in calling mtrace() and muntrace(). The
The command time is used to evaluate the performance
electric fence tool takes the least amount of time. In real
of Valgrind, Electric fence, Mtrace and Deleaker. For
scenarios, it should be noted that we have to take the
evaluating the performance of Mtrace, line 3, 11 and 15
various scenarios like thread safety, OS dependency issues
should be uncommented in code shown in Fig 17.

319

Authorized licensed use limited to: University of Petroleum & Energy Studies. Downloaded on August 23,2022 at 18:12:47 UTC from IEEE Xplore. Restrictions apply.
 into consideration in order to decide the usage of tools for
debugging our applications.

CONCLUSION AND FUTURE WORK

The memory leak and related issues if not taken care
of, can severely affect the performance of the application.
The manual inspection of code for these errors can be
tricky for applications containing billions of lines of code.
Memory debugging tools play an important role to ease
the burden of programmers. Yet, the programmer must
remain careful while writing the code itself to avoid
memory related issues to decrease the testing time of
application. Static as well as dynamic analysis tools
should be carefully used as and when needed for detecting
most of the memory leak errors. The four memory
debugging tools are discussed in this paper. The existing
memory leak approach suffers from reporting false
positive cases of memory leak (the cases where there is no
memory leak, but it is reported as memory leak). Memory
which is still reachable at the end of the program but has
not been freed. Therefore, there is a need to develop some
memory leakage detection tools which overcomes the
issue like reporting false positive cases of memory leak.
The future work includes developing such memory leak
fixing approaches.

REFERENCES
[1] C. Erickson, “Memory leak detection in embedded systems,”
Linux Journal, 2002.
[2] L. Cen, R. Marcus, H. Mao, J. Gottschlich, M. Alizadeh, and
T. Kraska, “Learned Garbage Collection,” Proceedings of the
4th ACM SIGPLAN International Workshop on Machine
Learning and Programming Languages, 2020, doi:
10.1145/3394450.
[3] X. Sun et al., “A Projection-Based Approach for Memory Leak
Detection,” Proceedings - International Computer Software
and Applications Conference, vol. 2, pp. 430–435, Jun. 2018,
doi: 10.1109/COMPSAC.2018.10271.
[4] G. Fan, R. Wu, Q. Shi, X. Xiao, J. Zhou, and C. Zhang,
“SMOKE: Scalable Path-Sensitive Memory Leak Detection for
Millions of Lines of Code,” Proceedings - International
Conference on Software Engineering, vol. 2019-May, pp. 72–
82, May 2019, doi: 10.1109/ICSE.2019.00025.
[5] S. Zhang, J. Zhu, A. Liu, W. Wang, C. Guo, and J. Xu, “A
Novel Memory Leak Classification for Evaluating the
Applicability of Static Analysis Tools,” Proceedings of the
2018 IEEE International Conference on Progress in
Informatics and Computing, PIC 2018, pp. 351–356, Jul. 2018,
doi: 10.1109/PIC.2018.8706142.
[6] B. Yu, C. Tian, N. Zhang, Z. Duan, and H. Du, “A dynamic
approach to detecting, eliminating and fixing memory leaks,”
Journal of Combinatorial Optimization 2019, pp. 1–18, Mar.
2019, doi: 10.1007/S10878-019-00398-X.
[7] M. M. Joy and F. J. Rammig, “A hybrid methodology to detect
memory leaks in soft real-time embedded systems software,”
International Journal of Embedded Systems, vol. 9, no. 1, pp.
61–73, 2017, doi: 10.1504/IJES.2017.081723.
[8] L. Garelli, A. Dabin, J. P. Dorsch, and M. A. Storti, “Use of
Valgrind’s Tool Suite and Profile-Guided Optimization in a
CFD Code,” Mecánica Computacional, vol. 36, no. 14, pp.
627–627, Nov. 2018, Accessed: June. 01, 2021. [Online].
Available: http://venus.santafe-
conicet.gov.ar/ojs/index.php/mc/article/view/5562
[9] “Electric Fence - eLinux.org.”
https://elinux.org/Electric_Fence (accessed June. 11, 2021).
[10] “mtrace(3) - Linux manual page.” https://man7.org/linux/man-
pages/man3/mtrace.3.html (accessed June. 02, 2021).
[11] W. Lim, S. Park, and H. Han, “Memory leak detection with
context awareness,” Proceeding of the 2012 ACM Research in
Applied Computation Symposium, RACS 2012, pp. 276–281,
2012, doi: 10.1145/2401603.2401664.

320

Authorized licensed use limited to: University of Petroleum & Energy Studies. Downloaded on August 23,2022 at 18:12:47 UTC from IEEE Xplore. Restrictions apply.
View publication stats