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 cou
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
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 al
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/s
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
> c
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 av
