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 http://cgit.collabora.co.uk/git/user/danni/gobject-list.git/tree/ or the similar refdbg http://gitorious.org/refdbg/refdbg which is packaged for Debian.
The gobject-list library is used like this:
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.