Dear all,

I've been trying to get clear on exactly what the situation between Gtk+ and 
Valgrind is. There is a fair amount of information out there, but it's pretty 
scattered and mainly fairly old, so it'd be good to get it all in one place.

As far as I understand it, the situation is that memory checkers like Valgrind 
throw a huge number of errors when used on Gtk programmes. This mainly seems to 
be due to memory which is allocated when the application begins, which needs to 
be kept for the entire lifetime of the programme. Since the memory will be 
freed by the OS when the application closes anyway, Gtk doesn't make an effort 
to track it and free it at the end.

This creates the problem that even though these aren't harmful, they give us a 
Valgrind log with thousands of entries which is almost impossible to interpret. 
The way to get around this is to generate a suppression file which tells 
valgrind that we don't want to treat these cases as leaks. We can also tell Gtk 
not to use some of its optimisations which will confuse Valgrind by setting the 
G_SLICE=always-malloc G_DEBUG=gc-friendly flags when we run Valgrind.

So, is this (fairly crude) summary correct and can anyone give me any more 
info? In particular, generating a suppression file from the output of valgrind 
is non-trivial and a real pain (c.f. 
http://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto).<http://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto%29.>
 It would be better if I knew which places Gtk does things which upset 
valgrind, so I could write the suppression file properly (rather than just 
trying to reverse engineer it from valgrind's output). So, can anyone give me a 
good explanation of exactly what/where Gtk (does to)/upsets Valgrind? Failing 
that, does anyone have a suppression file that works on the current version of 
Gtk?

Best wishes,

Tom
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Reply via email to