Re: [g-a-devel]Accessible_unref() and leaks
- From: Bill Haneman <bill haneman sun com>
- To: Michael Meeks <michael ximian com>
- Cc: "Padraig O'Briain" <Padraig Obriain sun com>, accessibility mailing list <gnome-accessibility-devel gnome org>
- Subject: Re: [g-a-devel]Accessible_unref() and leaks
- Date: 17 Sep 2002 11:30:54 +0100
On Tue, 2002-09-17 at 12:00, Michael Meeks wrote:
> Hi Padraig,
>
> On Tue, 2002-09-17 at 07:58, Padraig O'Briain wrote:
> > While sweeping at-poke for leaks I found that I needed to call
> > Accessible_unref() on the return value from Accessible_getChildAtIndex() but not
> > from the return value from Accessible_getParent().
>
> That sounds _extraordinarily_ odd;
>
> If you look at at-spi/libspi/accessible.c (..._get_parent) you see it
> calls spi_accessible_new_return with a FALSE release_ref - such that
> this doesn't release the ref on the parent - I imagine because I checked
> that atk_object_get_parent returned a ref on it's parent;
I take it you mean that you saw that "atk_object_get_parent () did not
increment the parent ref-count", thus the spi_accessible_new_return()
call didn't need to unref() the source object after the call;
the reason for spi_accessible_new_return()'s "unref" of the source
AtkObject being that either a pre-existing SpiAccessible is being
reused, or a new one created (with a consequential incrementing of the
AtkObject's ref count); in both cases an unref() would be appropriate to
balance the ATK ref-count.
[That is my recollection of the logic anyway...]
>
> It seems to do the CORBA ref counting just fine.
Yes, it seems so to me too, but it can get a little confusing, tracing
the ATK refcounts with respect to the Bonobo refcounts and the separate
issue of SpiAccessible creation/reuse.
So, worth digging a little deeper I guess.
-Bill
> > Is this what we expect to happen?
>
> No; but I don't see how the CORBA ref count can be wrong off hand;
> which ref count is not getting set correctly ?
>
> > If not, should this be fixed in at-spi or in gail?
>
> Hard to say.
>
> Incidentally, if you're beggining to notice performance issues with
> un-reffing stuff; there are 2 strategies I think we could take:
>
> a) Idle unreffing of the cspi reference cache;
> b) Async unrefs.
>
> b) Is pretty easy to implement, I plan to do it in libbonobo for 2.2;
> such that a bonobo_release_unref (obj, NULL); will never block /
> re-enter.
>
> HTH,
>
> Michael.
>
> --
> mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]