Copyright © 2007 and HCL proprietary material. All rights reserved. No part of this document may be reproduced, reused, modified or distributed, in whole or in parts, in any form by any means without prior written

authorization of HCL. The information provided in this document is intended for the sole use of the recipient and not for any commercial purpose. All the information provided is on “AS IS" basis and without warranties

of any kind either express or implied or to any derived results obtained by the recipient from the use of the information in the document. HCL does not guarantee the sequence, accuracy or completeness of the

information and will not be liable in any way to the recipient for any delays, inaccuracies, errors in, or omissions of, any of the information or in the transmission thereof, or for any damages what so ever arising there from.

WH

ITE

PA

PE

R

Get the Better of Memory Leaks with Valgrind Whitepaper

Memory leaks can cause problems and bugs in software which can be hard to detect. In this article we will discuss techniques and tools using which you can detect and fix memory leaks in your applications.

1. 3

2. 3

3. 3

4.

Introduction

Memory leak definition

Memory leak detection tools

Displaying Virtual Memory (VM) usage 3

5. Getting and installing Valgrind 4

6. Using Valgrind 4

7. Suppressing errors 4

8. Advantages of Valgrind 6

9. Limitations of Valgrind 6

10. Final Thoughts 6

Tabl

e of

Con

tent

s

1. Introduction

2. Memory leak definition

Today softwares are written with great innovation and

care. Extreme care is taken to ensure that the

software performs well, whether it is on the User

Interface (GUI) front, features or performance front.

With the growing advent of applications being

developed and ported on GNU/Linux it becomes

essential for a GNU/Linux developer to develop

software which caters to the user’s need and

performs well on a variety of hardware on which

GNU/Linux runs.

With the embedded domain on GNU/Linux really

catching up and the growing number of applications

being developed for embedded devices like mobiles,

PDAs, gaming consoles etc., it becomes essential to

have software which utilizes the limited memory

available on these systems and makes best use of it.

In spite of great care being taken for developing quality

software, developers are bound to make mistakes,

thus resulting in bugs in the software. One such bug

which can cause problems on PC and create havoc in

embedded devices is “Memory Leak”.

In this article, we will discuss about a free and open-

source tool called Valgrind using which you can easily

detect and fix memory leaks in your applications.

According to Valgrind manual: A memory leak is a part

of memory that has been allocated but not freed after

its usage or when pointer to a memory allocation is

deleted, thereby making the memory unusable. The

more often this memory leak occurs the more

valuable memory will be wasted and taken away from

other processes thereby affecting the whole system. If

your applications’ usage exceeds the virtual memory

size, it will crash the system.

According to Valgrind manual, some of the common

memory related errors are:

=Use of uninitialized memory.

=Reading/writing memory after it has been freed.

=Reading/writing off the end of malloced blocks.

=Reading/writing inappropriate areas on the stack.

=Memory leaks – where pointers to malloced blocks

are lost forever.

=Mismatched use of malloc/new/new[] vs

free/delete/delete[].

=Some misuses of the POSIX pthreads API.

Various tools are available for detecting memory leaks

and other bugs in your programs. The most popular

and well known tools are Purify (IBM) and Valgrind.

IBM’s Purify runs on GNU/Linux and Windows but is

proprietary and expensive. Being tux lovers we will

focus on a free, open-source memory-leak detection

tool called Valgrind.

To begin with, let’s check out the memory usage of

your application using a commonly used utility ‘ps’

available on all *nix platforms.

‘ps’ command displays the process status. Using the

various options available with it, it can be used for

displaying an application’s process-id, memory usage,

cpu-utilization etc. For example, to display the process

name, process id and VM usage of currently running

applications in the shell, following command should be

used:

Numerous options for the ‘ps’ command are available

through which you can view resource utilization of an

3. Memory leak detection tools

4. Displaying Virtual Memory (VM)

usage

$ ps -o cmd,pid,vsize

3

application.

If you have installed GNOME, you can use ‘gnome-

system-monitor’ command to view the process id, VM

usage etc. in a GUI window.

Using the above you can check the VM usage of your

application, but to dig deep inside your code for

memory leaks, you need Valgrind.

Tip: You can also use 'vmstat' command to display the VM

usage of your applications.

You can download the latest version of Valgrind from

t h i s m o n t h ’ s L F Y C D o r f r o m

http://valgrind.org/downloads/source_code.html.

For installing Valgrind first extract it:

Follow the three heavenly steps:

This would install Valgrind onto your system.

To check your application for memory leaks, place

valgrind before the application name while executing

the application.

Valgrind can be used on existing GNU/Linux

commands, for example:

This will display the ‘ps’ command output along with

detailed report by valgrind.

Valgrind includes various tools which can be used for

5. Getting and installing Valgrind

6. Using Valgrind

$ tar –jxvf valgrind-version.tar.bz2

$ cd valgrind-version

$ ./configure

$ make

$ make install

$ valgrind <application-name>

$ valgrind ps

detecting different types of problems. These are:

=memcheck: checks for memory leaks, accesses to

uninitialized memory etc.

=addrcheck: similar to memcheck but doesn't

perform thorough memory checking, runs faster and

uses less memory than memcheck.

=cachegrind: cachegrind is a cache simulator.

=massif: massif is a heap profiler.

=lackey: lackey is a sample tool that can be used as a

template for generating your own tools.

Tip: You can check out the Valgrind man page for more

details and options.

To specify the tool to be used, enter the following

command:

For e.g. for using the memcheck tool on an application

a.out, the command would be:

Valgrind, by default reports errors in all

programs/libraries installed on your GNU/Linux

system on which your application is dependent. Since,

we are interested in our own application; we can easily

suppress these errors by creating a .supp file and giving

its path while running Valgrind. Valgrind reads this file at

startup and suppresses errors having entry is in the

.supp file.

Tip: Details about the format of suppression files can be

found in the Valgrind manual.

A simple example using Valgrind

Let’s explore the beauty of Valgrind using a simple

example given below (Listing 1):

------------------------------CODE---------------------------

$ valgrind --tool=<toolname> <application-name>

$ valgrind --tool=memcheck ./a.out

$ va lgr ind --suppress ions=./suppf i le .supp

<application-name>

7. Suppressing errors

4

5

Listing 1:

#include <stdio.h>

#include <string.h>

int main()

{

char *p = (char *)malloc(20*sizeof(char));

strcpy(p, “linux rocks!”);

printf(“%s\n”, p);

return 0;

}

$ gcc -g -o listing1 listing1.c

$ valgrind --tool=memcheck ./listing1

ERROR SUMMARY: 0 errors from 0 contexts

(suppressed 18 from 1)

malloc/free: in use at exit: 20 bytes in 1 blocks.

malloc/free: 1 allocs, 0 frees, 20 bytes allocated.

LEAK SUMMARY:

definitely lost: 20 bytes in 1 blocks.

possibly lost: 0 bytes in 0 blocks.

still reachable: 0 bytes in 0 blocks.

suppressed: 0 bytes in 0 blocks

-----------------------------CODE----------------------------

In this program, we have allocated a memory of 20

bytes but it is not freed before the program exits. Let’s

analyze this program using Valgrind.

Compile this program using the following command:

Run the program using valgrind:

This will display a brief memory leak summary about

our program:

.

The memory leak summary clearly displays that we

have allocated 20 bytes using malloc() but we haven’t

freed the memory after use. The above memory leak

summary is very brief and doesn’t display the source-

code where we have allocated the memory. For

detailed memory-leak report, plug-in the following

command:

$ valgrind --tool=memcheck --leak-check=full

./listing1

ERROR SUMMARY: 0 errors from 0 contexts

(suppressed 18 from 1)

malloc/free: in use at exit: 20 bytes in 1 blocks.

malloc/free: 1 allocs, 0 frees, 20 bytes allocated.

20 bytes in 1 blocks are definitely lost in loss record 1

of 1

at 0x1B8FEA35: malloc (vg_replace_malloc.c:149)

by 0x8048375: main (listing1.c:4)

LEAK SUMMARY:

definitely lost: 20 bytes in 1 blocks.

possibly lost: 0 bytes in 0 blocks.

still reachable: 0 bytes in 0 blocks.

suppressed: 0 bytes in 0 blocks

Listing 2:

#include <stdio.h>

#include <string.h>

int main()

{

char *p = (char *)malloc(20*sizeof(char)); /*

Allocate 20 bytes of memory */

strcpy(p, “linux rocks!”);

printf(“%s\n”, p);

free(p); /* Free the allocated memory */

return 0;

}

This command displays the following output:

From the above output we can conclude that 20 bytes

of memory was allocated in listing1.c at line 4 but was

not freed after use. So, the correct code would be:

--------------------------------CODE-------------------------

-----------------------------CODE----------------------------

6

The Valgrind output for the above program is:

.

The above output indicates that all the allocates

memory has been freed and there are no memory

leaks in the application.

You can also save the Valgrind output to a log file and

view the memory leak details using a graphical front-

end such as Alleyoop as shown in Figure 1.

So, by using Valgrind and various tools available with it,

you can easily detect and fix memory leaks and other

memory-related bugs in your applications.

=Valgrind currently supports all major GNU/Linux

distributions on x86 architecture. Some of its

benefits include:

=Valgrind works directly with executables, so there is

no need to modify, recompile or relink your

applications.

=Valgrind can be used to debug small as well as large

applications.

ERROR SUMMARY: 0 errors from 0 contexts

(suppressed 18 from 1)

malloc/free: in use at exit: 0 bytes in 0 blocks.

malloc/free: 1 allocs, 1 frees, 20 bytes allocated

8. Advantages of Valgrind

=Valgrind can be used with other tools like GDB

(GNU Debugger), KDevelop (as a plug-in).

=It can be used with almost any kind of software

written in any language.

=It can be used as a platform for writing new

debugging tools.

=Valgrind is free, open-source and available under

GPL 2.

=Several graphical front-ends are available for Valgrind,

some of which include Alleyoop, Valgui, GNUGrind,

KDevelop (with Valgrind as a plug-in)

Every software has some limitations and Valgrind is no

exception.

=Application runs 25 to 50 times slower through

Valgrind.

=Memory consumption is increased while running

the application through Valgrind.

=Highly optimized code can sometimes cheat

Valgrind.

=Works only on GNU/Linux, x86 platforms.

Target Audience: GNU/Linux Programmers

Memory related bugs in software can be hard to

detect and fix. Using Valgrind and various graphical

front-ends available with it, you can easily detect and

fix memory leaks in your application. Efficient

utilization of memory, especially on embedded

systems is a must and Valgrind allows you to achieve

just that!

Refrences: This articles includes references from the

Valgrind Manual and is licensed under GNU Free

8. Limitations of Valgrind

9. Final Thoughts

Documentation License. For details about the GNU

F r e e D o c u m e n t a t i o n L i c e n s e , v i s i t

http://www.gnu.org/copyleft/fdl.html

7

Hello there. I am from HCL Technologies. We work behind the scenes, helping our customers to shift paradigms and start revolutions. We use digital engineering to build superhuman capabilities. We make sure that the rate of progress far exceeds the price. And right now, 45,000 of us bright sparks are busy developing solutions for 500 customers in 17 countries across the world.

Author Profile

Ramandeep Singh. Working as Lead Engineer at HCL Technologies Ltd and love singing, gaming, tinkering with different flavors of Unix and GNU/Linux. I can be contacted at ramandeeps@noida.hcltech.com