Re: Testing for memory leaks in GTK

[Simon McVittie <simon mcvittie collabora co uk>]

On Thu, 07 Jan 2010 at 08:59:38 +1100, Erik de Castro Lopo wrote:
> Does that mean I have to recompile glib in order to use this tool?

Debian's GLib packages compile GLib twice; the normal copy with
the recommended hidden-visibility settings ends up in /usr/lib in the normal
libglib2.0-0 binary package (which other packages depend on), but the package
also builds extra copy that is refdbg'able, and installs it in
/usr/lib/refdbg, in an additional libglib2.0-0-refdbg binary package
(you can use LD_LIBRARY_PATH to use this copy instead of the normal one
while refdbg'ing). If you're using Debian or a derivative; install that; if
not, see if your distribution's GLib maintainers can be persuaded to do
something similar?

(The bug in which this change was requested, which may provide some useful
background, is <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525915>)

refdbg itself isn't in Debian yet, unfortunately - when built from source
in the normal way it works fine, but when built with ./configure options
appropriate for a Debian package (e.g. targeting /usr) it doesn't seem to
work. <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525937> tracks the
progress of trying to get it in Debian.

(Jonny: any progress on this, or have you been too busy since you last tried?
Also, is your not-yet-working packaging available anywhere as a starting
point?)

valgrind is a generically applicable way to find *memory* leaks, but what
you're often interested in with GLib (or Python or any other refcounted
runtime) is to find *reference* leaks. valgrind will tell you that you've
leaked a MyObject, and the stack trace for its allocation, but that doesn't
really help you find the missing unref.

refdbg is more useful, as it will tell you the backtraces for (say) the 6
times it was allocated-or-reffed, and the 5 times it was unreffed; by pairing
off refs with unrefs in its log, you can find out which ref lacked a
corresponding unref, and fix it, much more easily.

Regards,
    Simon