Re: Valgrind and GTK
2010/1/2 : > Sorry, I posted hastily, I do get an annoying number of leaks if I let > it run a little longer, I see what you mean. I'm sure it wasn't as bad > back in 9.04. > > I'll try to make a better suppression file tomorrow. Here's another suppression file: http://www.vips.ecs.soton.ac.uk/development/nip2.supp With this, I now get no reported leaks or errors with a short run of my huge gtk program: ==3148== LEAK SUMMARY: ==3148==definitely lost: 120 bytes in 1 blocks ==3148==indirectly lost: 1,675 bytes in 46 blocks ==3148== possibly lost: 0 bytes in 0 blocks ==3148==still reachable: 893,032 bytes in 10,617 blocks ==3148== suppressed: 1,333,240 bytes in 21,362 blocks The 120 bytes is due to my XML pretty-printer and is deliberate. I get three reported possible leaks with the gtk "hello world" program, but I think they are due to the way the hello world program has been written: it quits in a button click callback, so there are various things left unfreed related to the button-up handling. No doubt I've made various errors, but maybe this will help someone. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
There has definitely been a degradation in the ability of valgrind to find memory leaks in gtk+ applications over the past, say, 5 years. I think the basic problem is that there are more singletons and that gtk+ object hold more pointers to other objects than they used to. IMHO, the situation could be greatly improved if there was a gtk+ function, say gtk_cleanup, that * Eliminated singletons * Cleared caches * Called similar cleanup functions for libraries used by gtk+ subject to the constraint that gtk_cleanup should leave the library in a usable state (and hence that you can call it as often as you want -- that's important for a library). Both fontconfig and cairo got this last point wrong. Their cleanup functions are basically only good for asserting that there were no leaks which is not helpful in the gtk+ case. As a consequence, pango is unable to clean up its object allocations. And I can't even blame Behdad. Maybe there should also be a function to handle all pending events at exit so the display related structures are not leaked. Note: the above proposal does nothing to address the type system related leaks, but they are the ones best suited for suppressions anyway. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
Sven Neumann wrote: > I agree that it would help a lot if we could in one way or another get > rid of false positives. But my experience shows that you get pretty much > the same valgrind warnings no matter how large your GTK+ application is. > Your 100 line demo program will produce the same set of warnings as your > 3 lines application (provided that your code doesn't have leaks). For a program that isn't leaking that would probably be correct. However, for helloworld I get: ==22566== LEAK SUMMARY: ==22566==definitely lost: 1,449 bytes in 8 blocks ==22566==indirectly lost: 3,716 bytes in 189 blocks ==22566== possibly lost: 4,428 bytes in 107 blocks ==22566==still reachable: 380,505 bytes in 7,898 blocks ==22566== suppressed: 35,873 bytes in 182 blocks and for my program (which I'm pretty sure does leak): ==12528== LEAK SUMMARY: ==12528==definitely lost: 12,997 bytes in 366 blocks ==12528==indirectly lost: 12,539 bytes in 470 blocks ==12528== possibly lost: 157,240 bytes in 5,219 blocks ==12528==still reachable: 920,186 bytes in 18,753 blocks ==12528== suppressed: 40,629 bytes in 284 blocks Looking at the valgrind log: http://www.mega-nerd.com/erikd/Blog/files/sweep-valgrind.txt.gz for me at least, its impossible to tell which ones I should be looking at or how to fix them. > But still it would make everyone's life easier if one wouldn't have to > differentiate between false and real positives manually. Perhaps > valgrind suppression files maintained and shipped with the libraries > would indeed be a good idea. Is there an up to date suppressions file I should try? 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: Valgrind and GTK
2010/1/3 Erik de Castro Lopo : > Erik de Castro Lopo wrote: >> Don't you think that maybe a suppression file is not the right approach >> to this problem? > > Specifically, I am concerned about the possibility of a suppressions file > that hides a real memory leak where a program bug continually allocates > resources that are not released *and* are suppressed by the supressions > file. I think suppressing reports from allocs inside g_type_create_*() and friends must be safe, since they can (by definition) only happen once. Libraries which don't use GObject often have a similar pattern and you can usually guess if an alloc comes from init from the stack trace. I agree that it's a bit more dangerous. I think you're arguing for GObject to add type deletion. It does support types in plugins that can be unloaded: http://library.gnome.org/devel/gobject/unstable/GTypePlugin.html I suppose GObject could be adapted so that all (most?) types were implemented this way and could be deleted, but the effort would be quite large, binary compatibility might be damaged, and the benefits would be rather small. > PS: I am the author of two well known libraries that have zero valgrind > warnings and errors (not even memory leaks) without the use of a > suppressions file. I think they are hard to avoid if you have a large number of dependencies (the number of libraries a GTK application links to under GNOME is eye-watering). People only usually make the effort to clean up on shutdown if their library can be loaded more than once, or might be repeatedly loaded and unloaded. Few libraries are like this :( John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
On Sat, 2010-01-02 at 14:40 +1100, Erik de Castro Lopo wrote: > I'm having trouble differentiating between memory leaks in my code and > apparent leaks in GTK when using valgrind. > > Even the minimal hello world program from the GTK tutorial: > >http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD > > when run as follows (suppression file from http://live.gnome.org/Valgrind): > > export G_SLICE=always-malloc > export G_DEBUG=gc-friendly > valgrind --tool=memcheck --leak-check=full --leak-resolution=high \ > --num-callers=50 --show-reachable=yes --suppressions=gtk.suppression \ > helloworld > helloworld-vg.txt 2>&1 > > on Ubuntu 9.10 reports this: > > ==22566== LEAK SUMMARY: > ==22566==definitely lost: 1,449 bytes in 8 blocks > ==22566==indirectly lost: 3,716 bytes in 189 blocks > ==22566== possibly lost: 4,428 bytes in 107 blocks > ==22566==still reachable: 380,505 bytes in 7,898 blocks > ==22566== suppressed: 35,873 bytes in 182 blocks > > If the leak summary of a 100 line demo program shows over 8000 definitely > lost, indirectly lost, possibly lost and and still reachable blocks, how > am I supposed to find the blocks of memory leaking from my code which is > 3 lines? I agree that it would help a lot if we could in one way or another get rid of false positives. But my experience shows that you get pretty much the same valgrind warnings no matter how large your GTK+ application is. Your 100 line demo program will produce the same set of warnings as your 3 lines application (provided that your code doesn't have leaks). But still it would make everyone's life easier if one wouldn't have to differentiate between false and real positives manually. Perhaps valgrind suppression files maintained and shipped with the libraries would indeed be a good idea. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
Tor Lillqvist wrote: > I think much of this boils down to the definition of "leak". My > impression is that GTK+ and GLib developers don't consider as leaks > once-only allocations that either indeed truly are unreachable almost > right away after being used (as long as they are small) (but of > course, if possible one should avoid these, too), or only unreachable > when the program is exiting. I tend to agree. That argument has merit, but its one that I cannot fully agree with. Regardless of the merits of that argument, my main problem is that it is so difficult to find real leaks amongst the thousands of false positives. I also have my doubts about the usage of valgrind suppression files. I have a suspicion (as yet unproven) that it would be possible to write a program which really does leak memory but which is reported as leak free by valgrind with the standard gtk suppressions file. 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: Valgrind and GTK
I think much of this boils down to the definition of "leak". My impression is that GTK+ and GLib developers don't consider as leaks once-only allocations that either indeed truly are unreachable almost right away after being used (as long as they are small) (but of course, if possible one should avoid these, too), or only unreachable when the program is exiting. I tend to agree. Serious leaks are such that keep leaking more and more as the program is running and as some code path is executed again and again. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
Erik de Castro Lopo wrote: > Don't you think that maybe a suppression file is not the right approach > to this problem? Specifically, I am concerned about the possibility of a suppressions file that hides a real memory leak where a program bug continually allocates resources that are not released *and* are suppressed by the supressions file. Erik PS: I am the author of two well known libraries that have zero valgrind warnings and errors (not even memory leaks) without the use of a suppressions file. -- -- 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: Valgrind and GTK
jcup...@gmail.com wrote: > Sorry, I posted hastily, I do get an annoying number of leaks if I let > it run a little longer, I see what you mean. I'm sure it wasn't as bad > back in 9.04. I've just tried the helloworld program on Ubuntu 9.04 and the results: ==23067== LEAK SUMMARY: ==23067==definitely lost: 1,551 bytes in 14 blocks. ==23067==indirectly lost: 3,716 bytes in 189 blocks. ==23067== possibly lost: 0 bytes in 0 blocks. ==23067==still reachable: 932,950 bytes in 5,960 blocks. ==23067== suppressed: 94,594 bytes in 1,897 blocks. are not too different from the results from 9.10: ==22566== LEAK SUMMARY: ==22566==definitely lost: 1,449 bytes in 8 blocks ==22566==indirectly lost: 3,716 bytes in 189 blocks ==22566== possibly lost: 4,428 bytes in 107 blocks ==22566==still reachable: 380,505 bytes in 7,898 blocks ==22566== suppressed: 35,873 bytes in 182 blocks > I'll try to make a better suppression file tomorrow. Don't you think that maybe a suppression file is not the right approach to this problem? 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: Valgrind and GTK
2010/1/2 Erik de Castro Lopo : >> for my 300,000 line GTK application. > > Is that public? In revision control somewhere? It's the nip2 GUI for the vips image processing library: http://www.vips.ecs.soton.ac.uk Sources here: http://vips.svn.sourceforge.net/viewvc/vips/ John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
2010/1/2 Erik de Castro Lopo : > With your suppressions file on the helloworld program from the GTK > tutorial and valgrind on Ubuntu 9.10 run as: Sorry, I posted hastily, I do get an annoying number of leaks if I let it run a little longer, I see what you mean. I'm sure it wasn't as bad back in 9.04. I'll try to make a better suppression file tomorrow. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
jcup...@gmail.com wrote: > Then run with: > > $ export G_SLICE=always-malloc > $ export G_DEBUG=gc-friendly > $ valgrind --leak-check=yes nip2 > valgrind.log 2>&1 > > And I get no reported leaks (well, one report from selinux and one > from a getpwd call somewhere) With your suppressions file on the helloworld program from the GTK tutorial and valgrind on Ubuntu 9.10 run as: $ export G_SLICE=always-malloc $ export G_DEBUG=gc-friendly $ valgrind --tool=memcheck --leak-check=full --leak-resolution=high \ --num-callers=50 --show-reachable=yes \ --suppressions=gtk.suppression2 \ helloworld > helloworld-vg.txt 2>&1 I get: ==29293== LEAK SUMMARY: ==29293==definitely lost: 1,449 bytes in 8 blocks ==29293==indirectly lost: 3,716 bytes in 189 blocks ==29293== possibly lost: 2,134 bytes in 41 blocks ==29293==still reachable: 333,811 bytes in 6,837 blocks ==29293== suppressed: 86,317 bytes in 1,323 blocks Full output here: http://www.mega-nerd.com/tmp/helloworld-vg.txt.gz > for my 300,000 line GTK application. Is that public? In revision control somewhere? 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: Valgrind and GTK
2010/1/2 Erik de Castro Lopo :
> when run as follows (suppression file from http://live.gnome.org/Valgrind):
I use the following suppression file on Ubuntu 9.10:
{
ldopen1
Memcheck:Addr4
obj:/lib/ld-2.6.1.so
}
{
xwrite1
Memcheck:Param
write(buf)
obj:/lib/ld-2.6.1.so
fun:_X11TransWrite
}
{
xwrite2
Memcheck:Param
writev(vector[...])
obj:/lib/ld-2.6.1.so
obj:/usr/lib/libX11.so.6.2.0
fun:_X11TransWritev
}
{
type_init
Memcheck:Leak
fun:*alloc
...
fun:g_type_register_*
}
{
type_init2
Memcheck:Leak
fun:*alloc
...
fun:g_type_init_*
}
{
type_init3
Memcheck:Leak
fun:*alloc
...
fun:g_type_create_*
}
Then run with:
$ export G_SLICE=always-malloc
$ export G_DEBUG=gc-friendly
$ valgrind --leak-check=yes nip2 > valgrind.log 2>&1
And I get no reported leaks (well, one report from selinux and one
from a getpwd call somewhere) for my 300,000 line GTK application.
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Valgrind and GTK
Hi all, I'm having trouble differentiating between memory leaks in my code and apparent leaks in GTK when using valgrind. Even the minimal hello world program from the GTK tutorial: http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD when run as follows (suppression file from http://live.gnome.org/Valgrind): export G_SLICE=always-malloc export G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --leak-resolution=high \ --num-callers=50 --show-reachable=yes --suppressions=gtk.suppression \ helloworld > helloworld-vg.txt 2>&1 on Ubuntu 9.10 reports this: ==22566== LEAK SUMMARY: ==22566==definitely lost: 1,449 bytes in 8 blocks ==22566==indirectly lost: 3,716 bytes in 189 blocks ==22566== possibly lost: 4,428 bytes in 107 blocks ==22566==still reachable: 380,505 bytes in 7,898 blocks ==22566== suppressed: 35,873 bytes in 182 blocks If the leak summary of a 100 line demo program shows over 8000 definitely lost, indirectly lost, possibly lost and and still reachable blocks, how am I supposed to find the blocks of memory leaking from my code which is 3 lines? I would also like to note that this is a problem faced by other libraries like GNU libc which solved the problem by adding a function __libc_freeres to free all its program lifetime allocated memory. I am aware of this bug: https://bugzilla.gnome.org/show_bug.cgi?id=64096 and some of the discussion around it: http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00279.html http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00541.html but I'm wondering if attitudes might have changed in the almost 10 years since that bug and thread. 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
