Re: [g-a-devel]Bug hunting

[Bill Haneman <bill haneman sun com>]

Hi Bernard:

> First, let me introduce my goal :
> I would like to log GUI <-> user interactions.
> In order to get meaninful event description, I need the GUI context of 
> the event. (mouse button clic is not enough, I want to know it's on a 
> button "OK" of the window "Open file").
> At-spi was the best thing I could find to do that.

Yes, I think at-spi can definitely do this for you.

> At first, I tought that I could simply register for the events, and 
> when it happens, follow the linkage from event->source with 
> getParent().
> Not so :-(
> When GUI elements are destroyed, the links are broken too fast :-(

Well, you should be able to call getParent() on the source object from
any events as long as you are still in the event callback.  If you need
to "save" the event and refer to it later, you can call
"AccessibleEvent_ref()" and then un-ref it later.  This will ensure that
the Accessible source object is still valid when you query it.  However
there may be cases in which the parent object is destroyed by this time.

> For now, I just decided not to collect the offending events, maybe it 
> would be possible to "pause" the closing app long enough...

This should not be necessary.  Which events are causing the problem?  If
the events you are seeing this with are not actually "state-changed"
events telling you that the object has gone "defunct", then I think
either dealing with the events in the callback (instead of keeping them
around and querying them later), or else using AccessibleEvent_ref(),
may solve your problems.  Also note API such as
AccessibleChildrenChangedEvent_getChildAccessible (), etc. which are not
subject to the race conditions which occur with use of the index
"detail" parameters from children-changed events.
 
> Is there any plan for implementing this function ?

There are concerns that this would be a bad idea.  Without going into
detail about why, it's possible that abuse of such an API would make a
mess of your session :-)
 
> I'll keep you informed if I think I encounter bugs (although it may be 
> my fault :-( ). Sometimes it'not easy to find that I'm the culprit ( 
> when eog segfaulted for example).
> 
> Now, for example, my code segfault in report_leaked_ref from SPI_exit 
> :-(
> 
> #0  0x73636269 in ?? ()
> #1  0x400fdb1d in ORBit_free (mem=0x40013280) at allocators.c:213
> #2  0x400fd9a5 in CORBA_free (mem=0x40013280) at allocators.c:138
> #3  0x4001f43a in SPI_freeString (s=0x40013280 "") at spi_main.c:488
> #4  0x4001f372 in report_leaked_ref (key=0x8097278, val=0x80972a0, 
>     user_data=0x0) at spi_main.c:422
> 
> Clearly I've done something wrong, but report_leaked_ref could be more 
> forgiving.

The intention was to, ahem, "force" the client to find+fix reference
counting bugs, I guess if the exit function were more forgiving it would
be tempting to ignore such problems.
> 
> Thank you for the offer for help, and for the great software !

Thanks, and best of luck!

- Bill
 
> Bernard
> 
> 
> 
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel