2008/5/2 Ionutz Borcoman <iborco@xxxxxxxxx>:
> 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
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
