RE: [gtk-list] Re: style usage + memory leak

[smolitor insight-tech com (Stephen Molitor)]

What is the ref count of the style if you destroy the button?

I'm very interested in this - it could indicate a big problem with Gtk+.

-----Original Message-----
From: Eric Harlow [mailto:linuxgeek@yahoo.com]
Sent: Thursday, October 29, 1998 12:37 PM
To: gtk-list@redhat.com
Subject: [gtk-list] Re: style usage + memory leak



Nope nope nope.  Ran a little test to see what the ref count was and
when the style was created, the ref count was 1.  Adding it to a
button makes the ref count be 3.   I suspect this is because it's
adding the style to the button and the contained label, but I haven't
verified this.  

 -Eric

---Stephen Molitor <smolitor@insight-tech.com> wrote:
>
> Well, I stand corrected.  I'm new to Gtk+, and I'm still trying to
get a
> handle on the reference counting stuff.
> 
> After reading refcounting.txt (in the docs directory of gtk+),
here's my new
> hypothesis:
> 
> When objects are created, their reference count is indeed 1 (not 0),
but
> they are flagged as
> "floating."  When an object is adopted by another widget, it's
floating flag
> is cleared, but
> the reference count is still 1.  So the effect is the same as if the
initial
> ref count were 0 - ordinarily, you do not need to (and should not)
call
> unref explicitly for objects you create, because ordinarily your
objects
> will be adopted (via gtk_container_add(), etc.) by another object. 
If you
> had to call unref() on every object you created, the reference
counting
> scheme would be worthless, since the whole purpose of reference
counting
> schemes is to avoid having to explicitly manage references.
> 
> Here's some quotes from refcounting.txt:
> 
> << start quotes >>>>>>>>>>>>>
> "When a GtkObject is created, it starts out in a special state called
> 'floating' (this is the twist).  This means that it is alive and has a
> reference to it, but the `owner' of this reference is not known. 
There are
> certain `potential owners' that will adopt a floating GtkObject.  For
> GtkWidgets the most common adopters are the parent widget."
> 
> <code excerpt from refcounting.txt>
> 
>  option_menu = gtk_option_menu_new ();
>   /* option_menu->ref_count == 1 and it is flagged as `floating'.
>    */
> 
>   gtk_container_add (window, option_menu);
>   /* option_menu->ref_count still == 1, but it is no longer
`floating'.
>    */
> 
> << end quotes >>>>>>>>>>>>>>>>
> 
> 
> I'm not sure of any of this, though!!!  I'm trying to understand by
writing
> about it, and having people correct my posts (selfish, I know). 
Also, I'm
> not at my Linux box write now, so I can't try any of this out.
> 
> Are any of the Gtk+ developers/documentors reading this thread? 
This seems
> like a very important topic not covered fully by the documentation.
> 
> 
> 
> -----Original Message-----
> From: Eric Harlow [mailto:linuxgeek@yahoo.com]
> Sent: Thursday, October 29, 1998 10:05 AM
> To: gtk-list@redhat.com
> Subject: [gtk-list] Re: style usage + memory leak
> 
> 
> 
> Hmm.. it does appear that all objects have a reference count of one
> when created.  I suppose the clean way is to do an unref on each
> object you create (ug..) during the program.  Otherwise, this
> certainly could cause leaks if you don't keep track of the memory.
> 
> To let GTK keep free the objects, could just unref the style after
> assigning it to the window.  Don't know what kind of damage that might
> do.  <g>
> 
> Don't know about the memory hogging though.  Might try replacing
> g_malloc with something more informative that keeps track of who's
> allocating the memory.  Might show what's going on.
> 
>  -Eric
> 
> ---Robert Roebling <roebling@sun2.ruf.uni-freiburg.de> wrote:
> >
> > Eric Harlow wrote:
> >
> > > You should not be calling unref unless you are also making the ref
> > > call.  If you just call the unref (as in your example), this
should
> > > end up freeing the style you just created.
> >
> > No. When I create the style, its ref count is 1. When I then
> > assign it to a widget, I assume the widgets will raise the
> > ref count to 2. Without unref after assigning it the widget
> > would unref the style upon its own destruction leaving
> > the ref count at 1 -> memory leak.
> >
> > > GTK keeps track of memory pretty well and you should rely on GTK
> > > to do that work for you.
> >
> > Daring thesis. Also GTK+ cannot handle memory on its
> > own, you'd still have to know when to unref unless you
> > use C++ which can do that itself. wxWindows does it for
> > you - as an aside...
> >
> > And I'm still wondering about the 1100 memory leaks reported
> > by dmalloc. It could be a cashing function. I hope it is.
> >
> >   Robert
> >
> > --
> > ------------------------------------------------------------------
> > Robert Roebling              "Write once, compile, run everywhere"
> >
> > wxWindows/GTK       http://wesley.informatik.uni-freiburg.de/~wxxt
> >
> > --
> > To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com <
> /dev/null
> >
> >
> 
> _________________________________________________________
> DO YOU YAHOO!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com <
/dev/null
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com <
/dev/null
> 
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-- 
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null