RE: Memory leaks and destruction of widgets

["Ian King" <king eiffel com>]

>Hang on, I may have misunderstood what was said. You do NOT need to
>worry about freeing the per-widget tooltip (the actual string).
>gtk_tooltips_set_tip() arranges things in such a way that if a widget
>is destroyed, the given tip goes away.

>The only thing you have to worry about is freeing the GtkTooltips
>object itself. You can in fact have a global GtkTooltips used
>throughout your app that you never destroy, and then write a
>convenience function that sets the tip on a widget using that object.


Okay, I do have a global tooltips object, I do have this convenience feature
that connects the tooltip text, but if I do not explicitly reset the tooltip
text with a NULL pointer then the memory just keeps going up and up... and
up.  I thought this was the solution to my problems, our application is
creating a lot of widgets and can leak up to half a megabyte per change of
state, tracking down this problem is a bit of a nightmare.


>> I really need to know if there are any other cases/scenarios such as this
>> where I have to call a function to release some memory due to a previous
>> action.  I am getting memory leaks due to the creation, usage and
disposal
>> of some widgets (either gtkpixmaps, gtkmenuitems, or gtklistitems). The
>> application I am trying to debug is huge and it is not easy finding where
>> the leak is.

>Well there are hundreds of such scenarios - anytime you allocate an
>object, you need to know how it will be freed. Welcome to the joy of
>the C programming language. ;-)

Apart from the obvious I meant, with tooltips being one.  As I am not
directly deallocating any memory (or unreferencing any object), just setting
the tooltip to a NULL pointer, I was wondering if there were any other
scenarios such as this.

I do not interface directly with C, we use gtk from an Eiffel wrapper
library (GEL), this is the platform dependant application layer for *unix,
on top of this wrapper library is our platform independant library
implementation (EiffelVision 2), on top of this is the application I am
trying to debug.  I have managed to fix all of the garbage collection
problems we were encountering, but I still get a leak from somewhere.  I
know it is something we are doing due to the interface with gtk as we do not
have this problem on Windows (where we use a Win32 wrapper library called
WEL).

Ian King