Re: Testing for memory leaks in GTK
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 gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
Simon McVittie wrote: 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 Yep, found and installed it. I now have: $ ls -l /usr/lib/refdbg/ total 2412 drwxr-xr-x 2 root root 4096 Jan 6 09:28 . drwxr-xr-x 331 root root 139264 Jan 6 20:33 .. -rw-r--r-- 1 root root 767414 Dec 4 00:54 libgobject-2.0.so -rw-r--r-- 1 root root 767414 Dec 4 00:54 libgobject-2.0.so.0 -rw-r--r-- 1 root root 767414 Dec 4 00:54 libgobject-2.0.so.0.2200.3 but I'm still not able to configure refdbg. I'm doing this: export LD_LIBRARY_PATH=/usr/lib/refdbg:$LD_LIBRARY_PATH ./configure --prefix=$HOME/Local and I still get his: *** * WARNING: glib = 2.6 found. refdbg will not work * * WARNING: unless you use it with glib compiled with * * WARNING: '--disable-visibility' or a version = 2.4.x. * * WARNING: See README for details.* *** What am I doing wrong? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
On Thu, Jan 7, 2010 at 4:10 PM, Erik de Castro Lopo mle+...@mega-nerd.com wrote: Simon McVittie wrote: 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 Yep, found and installed it. I now have: $ ls -l /usr/lib/refdbg/ total 2412 drwxr-xr-x 2 root root 4096 Jan 6 09:28 . drwxr-xr-x 331 root root 139264 Jan 6 20:33 .. -rw-r--r-- 1 root root 767414 Dec 4 00:54 libgobject-2.0.so -rw-r--r-- 1 root root 767414 Dec 4 00:54 libgobject-2.0.so.0 -rw-r--r-- 1 root root 767414 Dec 4 00:54 libgobject-2.0.so.0.2200.3 but I'm still not able to configure refdbg. I'm doing this: export LD_LIBRARY_PATH=/usr/lib/refdbg:$LD_LIBRARY_PATH ./configure --prefix=$HOME/Local you may well need to set PKG_CONFIG_PATH too. the autocrap files will be looking for glib-2.0.pc or something like that, and there's a good chance that they are finding the wrong one. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
Paul Davis wrote: On Thu, Jan 7, 2010 at 4:10 PM, Erik de Castro Lopo mle+...@mega-nerd.com wrote: Simon McVittie wrote: 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 Yep, found and installed it. I now have: $ ls -l /usr/lib/refdbg/ -rw-r--r-- 1 root root 767414 Dec 4 00:54 libgobject-2.0.so -rw-r--r-- 1 root root 767414 Dec 4 00:54 libgobject-2.0.so.0 -rw-r--r-- 1 root root 767414 Dec 4 00:54 libgobject-2.0.so.0.2200.3 but I'm still not able to configure refdbg. I'm doing this: export LD_LIBRARY_PATH=/usr/lib/refdbg:$LD_LIBRARY_PATH ./configure --prefix=$HOME/Local you may well need to set PKG_CONFIG_PATH too. the autocrap files will be looking for glib-2.0.pc or something like that, and there's a good chance that they are finding the wrong one. Is thats righ? I'm not sure. The library: /usr/lib/refdbg/libgobject-2.0.so.0.2200.3 should be a drop in replacement for /usr/lib/libgobject-2.0.so.0.2200.3 and pkg-config should be finding the pkg-config file for that ok while the LD_LIBRARY_PATH setting should be replacing the /usr/lib/ version with the /usr/lib/refdbg version. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
Tomeu Vizoso wrote: RefDbg is useful in these cases. I've had a look at RefDbg. On configure I get: *** * WARNING: glib = 2.6 found. refdbg will not work * * WARNING: unless you use it with glib compiled with * * WARNING: '--disable-visibility' or a version = 2.4.x. * * WARNING: See README for details.* *** Does that mean I have to recompile glib in order to use this tool? If so, this is not something people who develop *with* GTK are going to able to use. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
On Wed, Jan 6, 2010 at 22:59, Erik de Castro Lopo mle+...@mega-nerd.com wrote: Tomeu Vizoso wrote: RefDbg is useful in these cases. I've had a look at RefDbg. On configure I get: *** * WARNING: glib = 2.6 found. refdbg will not work * * WARNING: unless you use it with glib compiled with * * WARNING: '--disable-visibility' or a version = 2.4.x. * * WARNING: See README for details. * *** Does that mean I have to recompile glib in order to use this tool? If so, this is not something people who develop *with* GTK are going to able to use. While I agree that would be good to have something with a lower barrier, I think that building gtk+ and its dependencies in a dedicated prefix dir is a learning experience that will be of use to all users of gtk+. Jhbuild may help there. Regards, Tomeu Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
Tomeu Vizoso wrote: While I agree that would be good to have something with a lower barrier, Indeed. Currently, to debug memory leaks in code that uses GTK+ we have the widely known and used tool Valgrind which throws up many thousands of false positives or a GTK+ specific tool like RefDbg, which needs to be compiled from source and which also requires you to build the whole of the GTK+ stack from source. Sorry, but this situation is somewhat sub-optimal. I think that building gtk+ and its dependencies in a dedicated prefix dir is a learning experience that will be of use to all users of gtk+. What is it you expect people to learn from this experience? I've been using Linux since 1995 and back then I compiled just about everything from source, from binutils and gcc up. I really don't feel any nostalgia for those days. I currently do most of my development work on an older laptop which is both CPU and memory constrained. Building everything on that system would be a royal PITA in terms of build speed and would also require me to reclaim disk space currently used by other stuff. Fortunately, that system is about to be replaced with something pretty close to cutting edge where this won't be an issue. Jhbuild may help there. Yes, Jhbuild looks useful. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
You probably need to end with something like this
(from Gnumeric):
{
GSList *displays;
gdk_flush();
while (g_main_context_iteration (NULL, FALSE))
;/* nothing */
displays = gdk_display_manager_list_displays
(gdk_display_manager_get ());
g_slist_foreach (displays, (GFunc)gdk_display_close, NULL);
g_slist_free (displays);
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
On Tue, Jan 5, 2010 at 13:32, Erik de Castro Lopo mle+...@mega-nerd.com wrote: Hi all, I have written a small test program that can create independent toplevel windows based on a command line parameter. Currently these top level windows contain nothing more than a GtkLabel widget and destroy themselves using a g_timeout after 30 seconds. When all the toplevel windows have been destroyed the program calls gtk_main_quit() and then terminates. When this program is run under valgrind with an increasing number of top level windows I notice that number of blocks 'still reachable' when the program terminates increases with the number of top level windows created: Created Still reachable -- 1 397,039 bytes in 7,739 blocks 2 401,271 bytes in 7,786 blocks 3 405,111 bytes in 7,826 blocks 4 408,271 bytes in 7,847 blocks 5 412,399 bytes in 7,899 blocks Assuming that the bug isn't in my program, doesn't this look like a genuine leak that should be fixed? RefDbg is useful in these cases. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
On Tue, Jan 5, 2010 at 8:51 AM, Morten Welinder mort...@gnome.org wrote: You probably need to end with something like this useful, but that doesn't explain the dependency on the number of GtkWindows created, does it? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
Hi Erik, Am Dienstag, den 05.01.2010, 23:32 +1100 schrieb Erik de Castro Lopo: I have written a small test program that can create independent toplevel windows based on a command line parameter. Currently these top level windows contain nothing more than a GtkLabel widget and destroy themselves using a g_timeout after 30 seconds. When all the toplevel windows have been destroyed the program calls gtk_main_quit() and then terminates. Can you please post this program, so people can proofread/reproduce what you post? Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
On Tue, 2010-01-05 at 09:57 -0500, Paul Davis wrote: On Tue, Jan 5, 2010 at 8:51 AM, Morten Welinder mort...@gnome.org wrote: You probably need to end with something like this useful, but that doesn't explain the dependency on the number of GtkWindows created, does it? Generally, GdkWindow objects won't be released until DestroyNotify events for the corresponding X windows are received back from X. So if you don't wait for events, the more windows you create the more memory you will leak at program exit. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
Sven Herzberg wrote: Can you please post this program, so people can proofread/reproduce what you post? I now have two separate small programs which display this behaviour. The code can be retrieved use the Bzr revision control tool using: bzr get http://www.mega-nerd.com/Bzr/gtk-leak-tests The code is not visiable at that URL if you go there with a browser, you need to retrieve it using bzr. The two programs are: 00_multiple_toplevel/multiple_toplevel.c 01_multi_toplevel_w_button/multi_toplevel_w_button.c There is a single topleve Makefile that builds both programs. The programs can be run using: $program_name count where count is the number of top level windows to create. There is also a script in the top directory called leak-check.sh which can run a target test program from one to N times and generated a separate (slightly cleaned up) valgrind report log for each N. This script can be run like eg: ./leak-check.sh 0 00_multiple_toplevel/multiple_toplevel and produce file files vg1-multiple_toplevel.txt, vg2-multiple_toplevel.txt and so on. I'd appreciate it if someone could have a look at what I have so far. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
Tomeu Vizoso wrote: RefDbg is useful in these cases. Where can I get some more info on that? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
On Jan 5, 2010, at 4:45 PM, Erik de Castro Lopo wrote: Tomeu Vizoso wrote: RefDbg is useful in these cases. Where can I get some more info on that? Google knows all: http://www.google.com/search?q=refdbg first hit: http://refdbg.sourceforge.net/ -- Doing a good job around here is like wetting your pants in a dark suit; you get a warm feeling, but no one notices. -- unknown ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
