---
title: Valgrind
date: 2026-04-06
icon: valgrind.png
---

## Valgrind

### Purpose

_*Valgrind*_ is a free (GPLv3 licensed) tool you can use to debug memory usage of your program.

For example, I use it to check if I have memory leaks in programs I write in C.

### Download

You can go to [valgrind.org](https://valgrind.org) and [download](https://valgrind.org/downloads/current.html#current) the latest tarball of the Valgrind source code, or install the binary with your package manager.

If you want to compile it, download the tarball and untar it, then :

```sh
cd valgrind-*/
mkdir -v build
cd build
../configure
make
sudo make install
```

## Usage

### With your own programs

Let's make this example interactive, we will write a program that allocates and free some memory.

```c
cat << EOF > main.c
#include <stdlib.h>

int main(void)
{
	void *a = malloc(1);
	free(a);
	return 0;
}

EOF
```

Now compile the program with the following :

```sh
gcc main.c
```

We can then use Valgrind to see if this program has any memory leak.

```sh
valgrind ./a.out
```

The lines that we are interested in are these ones :

```txt
==1838== HEAP SUMMARY:
==1838==     in use at exit: 0 bytes in 0 blocks
==1838==   total heap usage: 1 allocs, 1 frees, 1 bytes allocated
==1838==
==1838== All heap blocks were freed -- no leaks are possible
```

So we know for sure that this program don't have any memory leak, but now remove the "free" statement at the end of the program, and recompile it.

```sh
sed -i '/free/d' ./main.c
gcc main.c
```

If you use Valgrind again, you will see these interesting lines :

```txt
==1901== LEAK SUMMARY:
==1901==    definitely lost: 1 bytes in 1 blocks
```

Which means we forgot to free some memory in our program. We can use the `--leak-check=full` flag for more details.

```txt
==2173== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2173==    at 0x484B8A8: malloc (vg_replace_malloc.c:447)
==2173==    by 0x400118E: main (in /home/tutorial/valgrind/a.out)
```

We only have one malloc in our program, so it is really easy to find from where the memory leak occurs, but let's suppose that we just can't find which `malloc` isn't freed, you can compile your program with debug info like so :

```sh
gcc -g main.c
```

Now Valgrind can specify the line.

```txt
==2197== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2197==    at 0x484B8A8: malloc (vg_replace_malloc.c:447)
==2197==    by 0x400118E: main (main.c:5)
```

### Some notes

Valgrind executes your code in some kind of """virtual""" CPU, so the program might run slower when debugging it with Valgrind.

You must know that recent CPU instructions might not be implemented in Valgrind, so if you have a recent CPU, and that you compile programs with optimization flags like `-march=native`, Valgrind will crash. All of your programs can't be debugged by Valgrind if you compile `glibc` with `-march=native` as the standard library (that is used by all of your programs) will use CPU instructions that aren't supported by Valgrind.

However, you can still use `-mtune=native` with for example `-march=x86-64` as compatibility will ALL x86_64 CPU will be enabled.

## What about MacOS/Windows

If you are on Windows, they advise to use Valgrind in WSL, for MacOS, the `leaks` programs should be already installed.

To search for memory leaks :

```sh
leaks --atExit -- ./a.out
```