Make Valgrind track your mempool

Warning: big post ahead!

If you are a programmer you have probably used or heard of the Valgrind tool. It is described as a framework for memory management and threading bugs detection. I usually use it to find out memory leaks or invalid memory access in my programs.

Valgrind is a great tool but think in the case of mempools. Usually you get a big memory area and manage it yourself during the life of the mempool and that area is only freed when the mempool is destroyed. If a user has requested a memory chunk but hadn’t returned it Valgrind can’t track that since it only knows about that big memory area previously allocated. Hmmm so what? Can’t we tell Valgrind what is going on?

Actually we can! Valgrind has a set of macros to allow you to track down what is happening in your mempool. Let’s learn how to use it. To do that I will use as example an EFL library I use a lot at ProFUSION called Eina.

Eina has two most used mempools: Chained and One big. The first one allocates a big memory area with malloc and manage chunks of it using a stack. The other is used when you know in advance how many objects of the same type you will have so it just calls malloc once. I will concentrate here in the Chained pool.

Before we start using the Valgrind’s macros we must understand the concepts of pool and superblock. These concepts are used in a very high level manner by Valgrind because of the many types of custom allocators existent. In Eina’s case the pool is the struct defining the mempool type and the superblock is the memory area from which chunks are given to the users, i.e, the stack pointer.

First of all we need to include valgrind’s header into our code. And we can do that allowing the users to completely ignore the macros (so avoiding some extra instructions when not running under valgrind) by declaring (or not) the NVALGRIND variable:

#ifndef NVALGRIND
# include <valgrind/memcheck.h>
#endif


Looking into the source code you can see that the mempool is created when the function eina_chained_mempool_init is called. Let’s tell valgrind the mempool was created by adding the call:

#ifndef NVALGRIND
VALGRIND_CREATE_MEMPOOL(mp, 0, 1);
#endif


The 3 macro’s arguments are the pool pointer, the number of redzone bytes and a “boolean” indicating whether the pool’s chunks are zeroed/defined. Chained pool does not use redzone bytes so we passed 0 to it. Similarly the mempool is destroyed in the function eina_chained_mempool_shutdown where we call:

#ifndef NVALGRIND
VALGRIND_DESTROY_MEMPOOL(mp);
#endif


Now we need to tell valgrind what is our superblock and when chunks are requested and returned. As we have already said the superblock is the stack pointer. It is called first in the struct and is initialized in _eina_chained_mp_pool_new internal function. As valgrind’s docs say we must mark it as NOACCESS:


#ifndef NVALGRIND
VALGRIND_MAKE_MEM_NOACCESS(ptr, pool->alloc_size - alignof);
#endif


where the second argument of the macro indicates the superblock size in bytes.

Finally the chunks are handle by the functions eina_chained_mempool_malloc and eina_chained_mempool_free. In the first one we add the call:

#ifndef NVALGRIND
VALGRIND_MEMPOOL_ALLOC(pool, mem, pool->item_alloc);
#endif


saying that a chunk of size pool->item_alloc was returned to the user with address given by mem and call:

#ifndef NVALGRIND
VALGRIND_MEMPOOL_FREE(pool, ptr);
#endif


to indicate the the chunk pointed by ptr was returned.

And that is all. Just run a program using the mempool inside valgrind and you will find out whether the pool is being correctly used. For more details you can take a look into the valgrind’s docs and in the Eina’s source code since I’ve commited that changes in revision 53405. Also in the commit message you will find a little program using it.

Just a reminder: if you want to use valgrind with eina you must ./configure it with the option –enable-valgrind.