Re: Valgrind and GTK

[jcupitt gmail com]

2010/1/3 Erik de Castro Lopo <mle+gtk mega-nerd com>:
> 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