Re: Memory leaks and destruction of widgets

[Havoc Pennington <hp redhat com>]

"Ian King" <king eiffel com> writes:
> 
> This really is not practical in most applications that display more than
> just a helloworld message :) We have a graphical debugger that is creating
> hundred of widgets on every debugging step, the memory that is consumed by
> just by the tooltips can be quite large, so the tooltips do really need to
> be removed once the widget is no longer needed.  It seems to me that there
> should have been a gtk_widget_set_tooltip as generally most widgets only
> have one tooltip associated with it.  If this ever needs to be changed then
> you reset the tooltip.  With the current way of doing things you can have a
> tooltip associated to a widget that no longer exists, which is of course
> bad.  This is not immediately obvious to most people that you have to
> explicitly remove the tooltip if you want this memory reclaimed, exemplified
> by a response to my previous message.

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.

Note, I agree that GtkTooltips is a brain-damaged API that has no
excuse for existence. ;-) It should clearly just be
gtk_widget_set_tooltip(). But you can make it emulate
gtk_widget_set_tooltip() with just a few lines of code, as described
above.

> 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. ;-)

A tool such as "memprof" is very helpful here, search for it on
google. Or if you have money to spend, there are several nice
commercial tools.

Havoc