Re: [Bug 111028] Dealing with reference cycles in GObject

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-04-25 at 11:34, J. Ali Harlow wrote:

> > > The current situation is that the reference counting is simply
> > > wrong which causes the bug I reported. The obvious way to fix
> > > it might be to count all references. However doing so causes
> > > the cycle I describe.
> > > 
> > > Ie., user calls gdk_pixmap_new() which creates a new GdkPixmap
> > > with a floating reference and then calls
> > > _gdk_win32_setup_pixmap_image() to create a new GdkImage with
> > > a floating reference. _gdk_win32_setup_pixmap_image() creates
> > > a reference to the associated GdkPixmap so does a g_object_ref
> > > followed by a gtk_object_sink.
> > 
> > I don't see any reference. Are you maybe looking at something
> > other than the current gtk2 branch code?
> 
> I'm looking at the 2.2.1 code. The reference from GdkImage to GdkPixmap
> is stored in image->windowing_data (gdkimage-win32.c line 118) and the
> reference from GdkPixmap to GdkImage is stored in pixmap_impl->image
> (gdkpixmap-win32.c line 310).

Just storing the pointer doesn't create a a reference; (C and GTK+ don't
have that sort of sophistication) you have to call g_object_ref() to 
create the reference.

> > >  Finally gdk_pixmap_new() does a g_object_ref/gtk_object_sink on 
> > >  the new GdkImage.
> > > 
> > > Net result: GdkPixmap returned to the user has reference count
> > > of 1 and the associated GdkImage also has a reference count
> > > of 1. This cycle will prevent the two objects ever being finalized
> > > unless somebody calls g_object_dispose() and the dispose()
> > > function was implemented.
> > > 
> > > At least, that's how I worked it out in my head. It could be
> > > a load of rubbish. I'm very much a GObject beginner.
> > 
> > Well, it sounds a little suspicious, since there are no floating
> > references at the GDK layer :-)
> > 
> > I must admit of bit of confusion trying to correlate your
> > mail with the current code.
> 
> Sorry; I did say I was a beginner with GObject. Yes, something
> else I discovered this morning was that Gdk doesn't use floating
> references which makes the detail of what I explained above wrong
> even if the basic idea is still valid.
> 
> In fact when I came to fix this using weak references as advised by
> Michael (thanks, btw) I found that the GdkPixmap->GdkImage reference
> really isn't important. It's only really there to have somewhere
> convenient to store the location of the pixel data in the pixmap
> and as an easy way of accessing the dimensions of that data. I
> have therefore put together a fix which removes this reference
> entirely which seems to solve the problem. Sadly it doesn't seem
> to have solved my resource leak but I'm still trying to debug
> that to see where it might be coming from.
> 
> I'll attach my fix.

I think what would be useful is to create the smallest test case
you can that leaks memory (make a tiny program with a loop that
just sits there and leaks memory), and then we should be able
to look at it and see if we can figure out what is going.

Regards,
                                             Owen