RE: qdata callback not called
- From: Murray Cumming Comneon com
- To: otaylor redhat com
- Cc: gtk-list gnome org, harald hopfes hopfes sysde eads net
- Subject: RE: qdata callback not called
- Date: Thu, 26 Jun 2003 18:06:47 +0200
> From: Owen Taylor [mailto:otaylor redhat com]
>
> On Thu, 2003-06-26 at 02:54, Murray Cumming Comneon com wrote:
> > I believe that the callback given to g_object_set_qdata_full()
> > should be called when the GObject is destroyed, but it
> doesn't seem to work
> > in this simple test case:
> > http://bugzilla.gnome.org/showattachment.cgi?attach_id=17788
> >
> > Have I made a simple mistake in that test code, or am I
> misunderstanding
> > something?
> >
> > We use this in the internals of gtkmm and I'm sure it works
> most of the
> > time, so I am confused. We can of course just connect to
> the "destroy"
> > signal if we can't get this to work consistently.
>
> qdata is freed on finalize, not on destroy. Your example leaks
> the button, so the qdata will never be freed.
I thought it might be something like this. I guess we'll watch for destroy
rather than finalize.
> The reason that it leaks is probably most apparent if you
> understand why it is *not* leaked in the normal case:
>
> create button: reference count 1, floating
> add button to container: container adopts button, reference count 1,
> not floating
> destroy button: button is removed from parent, reference
> count drops to 0, finalized
>
> But if you destroy a floating button, nothing will happen to
> the reference count.
OK, thanks. Out of interest, can we explicitly finalize the button, or do we
have to add it to a container, then destroy it, in order to avoid the leak.
Murray Cumming
murrayc usa net
www.murrayc.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]