Re: checking for memory leaks in gtk

[jcupitt gmail com]

2008/5/2 Ionutz Borcoman <iborco gmail com>:
>  I'm trying to find a way to test for memory leaks in GTK+ apps. I've created a
>  very simple HelloWorld app and profiled it with valgrind.
>
>  I have run valgrind as:
>
>   G_SLICE=always-malloc G_DEBUG=gc-friendly \
>     valgrind --tool=memcheck --leak-check=full --leak-resolution=high \
>     -num-callers=20 ./helloworld &> helloworld.out

That sounds OK, though you will get a lot of output. I generally just use

G_SLICE=always-malloc G_DEBUG=gc-friendly \
     valgrind --tool=memcheck ./helloworld &> helloworld.out

You could look at memprof as well, it's a bit basic compared to
valgrind, but programs run at (almost) full speed, it has a nice GUI,
and it shows your memory use as the program runs.

>  ==15450== LEAK SUMMARY:
>  ==15450==    definitely lost: 429 bytes in 5 blocks.
>  ==15450==    indirectly lost: 180 bytes in 13 blocks.
>  ==15450==      possibly lost: 800 bytes in 20 blocks.
>  ==15450==    still reachable: 362,035 bytes in 9,875 blocks.
>  ==15450==         suppressed: 0 bytes in 0 blocks.
>
>  I'm surprised that even for such a simple program I still get memory leaks. So
>  I'm probably doing something wrong.

The gtype system doesn't free a lot of stuff on exit (there's no
point), so you will see reported leaks. I believe xlib fails to free a
number of singleton classes as well. But these leaks won't grow over
time, so they are not really leaks.

When I valgrind my app and check for leaks, I let it run for a while
before quitting, then check the output for repeated allocations. If I
see the same thing being allocated several times and not freed I know
I probably have a leak.

I have stumbled upon a few leaks in GTK over the years (and submitted
patches, heh), but really rather few. You can write large programs
with GTK and have them run for a very long time.

John