Re: [g-a-devel]checking Accessible* validity

[David Bolter <david bolter utoronto ca>]

Hi Michael,

Michael Meeks wrote:

> Hi David,
>
> On Thu, 2002-12-19 at 15:15, David Bolter wrote:
>
> > That should help actually.  I think it could potentially be a good thing 
> > for many at-spi clients, but I am not aware of the efficiency costs.
>
> 	There is ~0 efficiency cost to emit a slew of 'defunct' events on every
> Accessible we have kicking around when the remote app dies - it's a
> trivial and (mostly) foolproof thing to do. [ it may not like the
Great!

> JavaORB depending on how 31337 it is ;-]
>
> > > 	Badness ? really ? what sort ? you should be able to reliably invoke
> > > these methods in perpetuity without pathalogical failure - ok so you'll
> > > get bogus roles [etc.] back, but ...
> > The example is that gok seg faults (when it tries an Accessible_getName 
> > ([accessible for defunct object]);  I am not sure why it seg faults. 
> > Note that the process space for gedit is gone at this point.
>
> 	Well - the defunctness of the object should make no difference at all.
> This is a bug in gok (or possibly cspi). It sounds like someone is not
> ref counting the Accessible * correctly. Now of course - since the same
> Accessible * is shared across the whole process ( to make a == b) work
> nicely, it's not necessarily at the place you're looking ;-) which may
> make things more tricky.
>
> 	Are you certain you're not 'taking' a const Accessible * from an event
> emission and later un-reffing it ? then again it's prolly a cspi bug ;-)
> A stack trace would really help (are you using HEAD at-spi)?
Yes HEAD at-spi.  It's the only way to go ;-)

> > > 	I'm thinking of caching some of the details [ such as role-type ] so we
> > > could use that to nicely flag /tag a defunct state perhaps for fast
> > > polling.
> > I think I understand you here, but if the cache is finite then there is 
> > still no gaurantees...
>
> 	Ah - but we'd cache it by expanding the Accessible* and stashing the
> 'role' on it - so it'd never expire, and be a nice fast way to poll
> individual handles for deadness :-)
>
> > at-poke seems to be working for me...  but does it log events?
>
> 	Nope; it doesn't.
>
> > I am still using Accessible_ref and Accessible_unref on the 
> > event->source.  I have been on leave for a few months and am a little 
> > out of the loop.  Should I be using AccessibleEvent_ref/unref?  Note, I 
> > am doubtful that will solve this particular issue.
>
> 	It won't solve the immediate issue. I'd recommend trying to binary chop
> the problem out and/or auditing all cases of Accessible_unref but first
> hack cspi/spi_main.c and #define DEBUG_OBJECTS which stops at-spi from
> actually freeing the last ref - if that makes the problem go away - you
> know you have a ref counting bug ;-) [ having said that we zap the
The problem went away.  I will look into the reference counts (although 
we already keep a close watch on this programmatically).

It would be helpful for me to know the expected behavior for the 
following situation:
If we (gok) have an Accessible* (call it ac) for gedit's menu object, 
and from our perspective the reference count is at least 1.  Then gedit 
dies and we are not aware.  What is the expected behavior if if we 
subsequently call one of the Accessible_XXXX(ac) methods?  (I suppose it 
depends on whether the at-spi is also unaware gedit died.)

Also what if we call these methods with bogus addresses?  E.g. 
Accessible_getName(0x12345);  What is the expected behavior?

thanks very much for your help so far,

~~David

> structure on free with 0xaa so if you see that value around you also
> know ;-]
>
> 	HTH,
>
> 		Michael.