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 _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
