Valgrind is a tool that can detect memory leaks and errors. It provides a heap summary, leak summary, and error summary in its output. A memory leak example is analyzed that allocates memory without freeing it later. Running the example through Valgrind confirms there is a leak reported. Another example without a leak is also shown, and Valgrind correctly reports no leaks. Steps are provided for running Valgrind on Android applications to check for memory leaks from native code.

1. How to Perform Memory Leak Test Leveraging Valgrind
Presented by: Muhammed Nisar PK, Senior Software Engineer-Testing

2. How to Perform Memory Leak Test Leveraging Valgrind
© RapidValue Solutions Confidential 2
How to Perform Memory Leak Test Leveraging Valgrind
1. Install Valgrind:
$sudo apt install valgrind # Ubuntu, Debian, etc.
2. Install gcc:
* gcc stands for GNU Compiler Collections. This is used to compile mainly C and C++ language.
$sudo apt install gcc
3. Let us consider a C program test.c with memory leak
The code represents that the memory
allocated for pointer ‘ptr’ (a size of ‘int’ which
is 4 bytes) which are not freed.
So probably this should be detected as
memory leak.
4. Give file permission for the sample program file:
$chmod 777 test.c
5. Compile the program:
$gcc -Wall -g test.c -o test
6. Run the program along with valgrind:
$valgrind --leak-check=yes ./test
or
$valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose --log-file=valgrind-out.txt
./test (This will create one file with valgrind logs)
#include<stdio.h>
#include<string.h>
#include<stdlib.h>
int main(void) {
int * ptr = (int * ) malloc(sizeof(int));
/* Do some work */
return 0; /* Return without freeing ptr*/
}

3. How to Perform Memory Leak Test Leveraging Valgrind
© RapidValue Solutions Confidential 3
nisar@RVSKCH33DT:~$ valgrind --leak-check=yes ./test
==2013== Memcheck, a memory error detector
==2013== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2013== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==2013== Command: ./test
==2013==
==2013==
==2013== HEAP SUMMARY:
==2013== in use at exit: 4 bytes in 1 blocks
==2013== total heap usage: 1 allocs, 0 frees, 4 bytes allocated
==2013==
==2013== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2013== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-
linux.so)
==2013== by 0x10865B: main (test.c:7)
==2013==
==2013== LEAK SUMMARY:
==2013== definitely lost: 4 bytes in 1 blocks
==2013== indirectly lost: 0 bytes in 0 blocks
==2013== possibly lost: 0 bytes in 0 blocks
==2013== still reachable: 0 bytes in 0 blocks
==2013== suppressed: 0 bytes in 0 blocks
==2013==
==2013== For counts of detected and suppressed errors, rerun with: -v
==2013== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Result

4. How to Perform Memory Leak Test Leveraging Valgrind
© RapidValue Solutions Confidential 4
There are 3 main parts to Valgrind output:
1. The Heap Summary tells you the number of bytes in use when the program exits, the number of
memory allocations (anytime the new operator is used), the number of frees (whenever the delete
operator is used), and the total number of bytes allocated.
2. The Leak Summary tells you what memory your program might have leaked. Anything lost means that
some heap-allocated memory can no longer be reached by your program. In general, all memory
should be tracked and none should be untracked.
3. The Error Summary tells you how many errors occurred during the execution of your program.
The above result shows “definitely lost: 4 bytes in 1 blocks” which represents the memory leak. Any
leaks listed as "definitely lost" should be properly fixed (as should ones listed "indirectly lost" or
"possibly lost" -- "indirectly lost" happens when you do something like freeing the root node of a tree but
not the rest of it, and "possibly lost" indicates that the memory is actually lost). If the program with
definitely lost runs for a long time, it will use a lot of memory that is not needed. The above example
says the program allocates a buffer and returns it, but the caller never frees the memory after it is
finished.
1. Similarly let us consider a C program test.c without memory leak.
2. Compile the program:
$gcc -Wall -g test.c -o test
3. Run the program along with valgrind:
$valgrind --leak-check=yes ./test
The result shows “All heap blocks were freed -- no leaks are possible” which represents that there is no
memory leak.
R
#include<stdio.h>
#include<string.h>
#include<stdlib.h>
int main(void) {
int * ptr = (int * ) malloc(sizeof(int));
/* Do some work */
free(ptr);
return 0; /* Return without freeing ptr*/
}
The code represents that
the memory allocated for
pointer ‘ptr’ (a size of ‘int’
which is 4 bytes) which
are freed. So probably
there should not be a
memory leak.

5. How to Perform Memory Leak Test Leveraging Valgrind
© RapidValue Solutions Confidential 5
nisar@RVSKCH33DT:~$ valgrind --leak-check=yes ./test
==2372== Memcheck, a memory error detector
==2372== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2372== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==2372== Command: ./test
==2372==
==2372==
==2372== HEAP SUMMARY:
==2372== in use at exit: 0 bytes in 0 blocks
==2372== total heap usage: 1 allocs, 1 frees, 4 bytes allocated
==2372==
==2372== All heap blocks were freed -- no leaks are possible
==2372==
==2372== For counts of detected and suppressed errors, rerun with: -v
==2372== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Result
How to Perform Memory Leak Test Leveraging Valgrind in Android
1. Download Valgrind and cross compile the package for android platform using “. /configure” option under
valgrind folder.
2. Step 1 requires supported android “NDK” with test devices CPU compatible platforms (like ARM, X86 etc.).
3. Push the valgrind package to android device.
4. Set “VALGRIND_LIB”
$ export VALGRIND_LIB /data/local/tmp/Inst/lib/valgrind
$ /data/local/tmp/Inst/bin/valgrind --version
$ valgrind-3.13.0
5. Install Android APP(With JNI) with debug enabled mode in to android device.
6. Start valgrind using following comment.

6. How to Perform Memory Leak Test Leveraging Valgrind
© RapidValue Solutions Confidential 6
$ VGPARAMS='-v --error-limit=no --trace-children=yes --log-file=/sdcard/valgrind.log.%p --
tool=memcheck --leak-check=full --show-reachable=yes'
$ exec /data/local/tmp/Inst/bin/valgrind $ VGPARAMS
7. Start Android APP(With JNI) using
$ adb shell am start -a android.intent.action.MAIN -n $PACKAGE/.HelloJni
8. The log file should be generated and can be grep by using adb shell ls -lR "/sdcard/*grind*"

7. How to Perform Memory Leak Test Leveraging Valgrind
© RapidValue Solutions Confidential 7
RapidValue is a leading provider of end-to-end mobility, omni-channel, IoT and cloud solutions to
enterprises worldwide. Armed with a large team of experts in consulting, UX design, application
engineering and testing, along with experience delivering global projects, we offer a range of services
across various industry verticals. RapidValue delivers its services to the world’s top brands and Fortune
1000 companies, and has offices in the United States and India.
Disclaimer:
This document contains information that is confidential and proprietary to RapidValue Solutions Inc. No part of it may be used,
circulated, quoted, or reproduced for distribution outside RapidValue. If you are not the intended recipient of this report, you are
hereby notified that the use, circulation, quoting, or reproducing of this report is strictly prohibited and may be unlawful.
© RapidValue Solutions
www.rapidvaluesolutions.com/blogwww.rapidvaluesolutions.com
+1 877.643.1850 contactus@rapidvaluesolutions.com