memory leak debugging

In Bluefish, Gnome, open source, Programming on May 7, 2011 by oli4444

For long running applications it is important that there are no memory leaks. For an application that runs for a short time the memory will be freed after the application quits, but for an application that runs for days or weeks or more, any memory that is allocated by the application should be free’ed by the application, otherwise I will not be available for other programs for a long time.

A very useful tool for memory leak debugging is valgrind. It makes your program run a lot slower (10X?) but it will resturn all interesting memory allocations that have not been explicitly free’ed. GTK does one thing that valgrind doesn’t like: the slice allocator does it owns memory management. Memory seems to be leaking, but it is ready to be used by the slice allocator. Luckily you can turn that off with the environment variable G_SLICE=always-malloc.

$ G_SLICE=always-malloc valgrind --tool=memcheck src/bluefish

valgrind will now report if you have memory leaks. To see where the leaking memory is allocated use

$ G_SLICE=always-malloc valgrind --tool=memcheck --leak-check=full --num-callers=32 src/bluefish

Valgrind will show several false positives, that is memory that gtk is allocating that is not supposed to be free’ed.

Sometimes the origin of the memory leak is not good enough, because it is a reference counted gobject, and you can’t find where the reference is increased that-should-have-been-decreased or another bug like that. A useful tool to debug that is the gobject-lifetime debugger library or the similar refdbg which is packaged for Debian.

The gobject-list library is used like this:

LD_PRELOAD=~/ src/bluefish

I get a lot of output here, and there seem to many false positives (I hope, because valgrind doesn’t report them!?!). I have to play with this a little more to learn how to use it effectively.


2 Responses to “memory leak debugging”

  1. Once you’ve plugged all your leaks using memcheck, you can then check out the massif tool that valgrind provides, which will give you snapshots throughout time of where memory was allocated. This is very useful for memory allocations which are still being tracked … but aren’t really needed.

    A good companion tool to massif is the massif visualizer, a qt application which allows you to have a graphical view of those allocations over time, filter them and figure out where you’ve got memory leaks.

  2. It’s possible to make your allocators inform valgrind when they allocate, deallocate, and reallocate memory. There’s a valgrind.h floating around somewhere which makes it mostly trivial to link in valgrind and get things going. Of course, that requires such support to be compiled in, but if there’s already environment-variable support for configuring the allocator, that can’t be such a huge burden, and it would have more than a few benefits too.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: