# diff -u orca.py.bak orca.py
--- orca.py.bak	Wed May  7 17:24:13 2008
+++ orca.py	Wed May  7 18:31:15 2008
@@ -1128,7 +1128,7 @@
         _PRESENTATION_MANAGERS = \
             [focus_tracking_presenter.FocusTrackingPresenter()]
 
-    _switchToPresentationManager(0) # focus_tracking_presenter
+#    _switchToPresentationManager(0) # focus_tracking_presenter
 
     if settings.timeoutCallback and (settings.timeoutTime > 0):
         signal.alarm(0)
@@ -1136,7 +1136,10 @@
     if settings.cacheValues:
         pyatspi.setCacheLevel(pyatspi.CACHE_PROPERTIES)


After disable focus tracking presenter, java applications don't crash. I'm not familiar with orca. Willie, do you have any comments?

(In reply to comment #1)
> # diff -u orca.py.bak orca.py
> --- orca.py.bak Wed May  7 17:24:13 2008
> +++ orca.py     Wed May  7 18:31:15 2008
> @@ -1128,7 +1128,7 @@
>          _PRESENTATION_MANAGERS = \
>              [focus_tracking_presenter.FocusTrackingPresenter()]
> 
> -    _switchToPresentationManager(0) # focus_tracking_presenter
> +#    _switchToPresentationManager(0) # focus_tracking_presenter
> 
>      if settings.timeoutCallback and (settings.timeoutTime > 0):
>          signal.alarm(0)
> @@ -1136,7 +1136,10 @@
>      if settings.cacheValues:
>          pyatspi.setCacheLevel(pyatspi.CACHE_PROPERTIES)
> 
> 
> After disable focus tracking presenter, java applications don't crash. I'm not
> familiar with orca. Willie, do you have any comments?
> 

Disabling the focus tracking presenter is kind of like not running Orca at all.  That is, the focus tracking presenter is Orca's primary operating mode.  It is what ends up registering for the majority of AT-SPI events, which are then processed by Orca.

I believe the problem lies somewhere with the AT-SPI event delivery/processing.

Willie, I agree.

But you know all events comes from java applications will be sent to AT via registryd, no matter whether orca is started or not, this event transfer is same. I think the most possibility is that the crash happens when AT invokes some corba method provided by java applications. So it will be useful if i can trace which method orca calls when java crashes.

I think it will be better if you could me some suggestions about ORCA code.

(In reply to comment #3)
> Willie, I agree.
> 
> But you know all events comes from java applications will be sent to AT via
> registryd, no matter whether orca is started or not, this event transfer is
> same. I think the most possibility is that the crash happens when AT invokes
> some corba method provided by java applications. So it will be useful if i can
> trace which method orca calls when java crashes.
> 
> I think it will be better if you could me some suggestions about ORCA code.
> 

Unfortunately, this isn't limited to just Orca.  :-(  Here's another way to reproduce the problem:

1) Run SwingSet2
2) Run accerciser
3) Select SwingSet2 in accerciser
4) Go to accerciser's "Event Monitor" tab
5) Select "Selected application" as the source
5) Select just the "focus" event to monitor
6) Go back to SwingSet2 and press Alt+f, you'll get this stack trace:

bash-3.2$ java -jar /usr/java/demo/jfc/SwingSet2/SwingSet2.jar 
May 7, 2008 10:18:33 AM com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl convertThrowableToSystemException
WARNING: "IOP00010202: (UNKNOWN) Unknown user exception thrown by the server"
org.omg.CORBA.UNKNOWN:   vmcid: SUN  minor code: 202 completed: Maybe
	at com.sun.corba.se.impl.logging.ORBUtilSystemException.runtimeexception(ORBUtilSystemException.java:8365)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.convertThrowableToSystemException(CorbaMessageMediatorImpl.java:1918)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1868)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1821)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1548)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:922)
	at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:181)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:694)
	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:451)
	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1189)
	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:398)
Caused by: java.lang.RuntimeException: handleThrowableDuringServerDispatch: cannot create response.
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1845)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1821)
	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:258)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1680)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1540)
	... 6 more
Caused by: org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 203  completed: No
	at com.sun.corba.se.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:2231)
	at com.sun.corba.se.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:2253)
	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.writeLock(SocketOrChannelConnectionImpl.java:933)
	at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:78)
	at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.overflow(BufferManagerWriteStream.java:51)
	at com.sun.corba.se.impl.encoding.CDROutputStream_1_2.grow(CDROutputStream_1_2.java:211)
	at com.sun.corba.se.impl.encoding.CDROutputStream_1_2.alignAndReserve(CDROutputStream_1_2.java:182)
	at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.internalWriteOctetArray(CDROutputStream_1_0.java:547)
	at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_octet_array(CDROutputStream_1_0.java:567)
	at com.sun.corba.se.impl.encoding.CDROutputStream.write_octet_array(CDROutputStream.java:169)
	at com.sun.corba.se.spi.servicecontext.UnknownServiceContext.write(UnknownServiceContext.java:43)
	at com.sun.corba.se.spi.servicecontext.ServiceContexts.writeMapEntry(ServiceContexts.java:322)
	at com.sun.corba.se.spi.servicecontext.ServiceContexts.writeServiceContextsInOrder(ServiceContexts.java:283)
	at com.sun.corba.se.spi.servicecontext.ServiceContexts.write(ServiceContexts.java:247)
	at com.sun.corba.se.impl.protocol.giopmsgheaders.ReplyMessage_1_2.write(ReplyMessage_1_2.java:175)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2199)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2162)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.createSystemExceptionResponse(CorbaMessageMediatorImpl.java:2087)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1871)
	... 19 more
May 7, 2008 10:18:45 AM com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl convertThrowableToSystemException
WARNING: "IOP00010202: (UNKNOWN) Unknown user exception thrown by the server"
org.omg.CORBA.UNKNOWN:   vmcid: SUN  minor code: 202 completed: Maybe
	at com.sun.corba.se.impl.logging.ORBUtilSystemException.runtimeexception(ORBUtilSystemException.java:8365)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.convertThrowableToSystemException(CorbaMessageMediatorImpl.java:1918)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1868)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1821)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1548)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:922)
	at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:181)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:694)
	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:451)
	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1189)
	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:398)
Caused by: java.lang.RuntimeException: handleThrowableDuringServerDispatch: cannot create response.
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1845)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1880)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1821)
	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:258)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1680)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1540)
	... 6 more
Caused by: org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 203  completed: No
	at com.sun.corba.se.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:2231)
	at com.sun.corba.se.impl.logging.ORBUtilSystemException.writeErrorSend(ORBUtilSystemException.java:2253)
	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.writeLock(SocketOrChannelConnectionImpl.java:933)
	at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:78)
	at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.overflow(BufferManagerWriteStream.java:51)
	at com.sun.corba.se.impl.encoding.CDROutputStream_1_2.grow(CDROutputStream_1_2.java:211)
	at com.sun.corba.se.impl.encoding.CDROutputStream_1_2.alignAndReserve(CDROutputStream_1_2.java:182)
	at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.internalWriteOctetArray(CDROutputStream_1_0.java:547)
	at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_octet_array(CDROutputStream_1_0.java:567)
	at com.sun.corba.se.impl.encoding.CDROutputStream.write_octet_array(CDROutputStream.java:169)
	at com.sun.corba.se.spi.servicecontext.UnknownServiceContext.write(UnknownServiceContext.java:43)
	at com.sun.corba.se.spi.servicecontext.ServiceContexts.writeMapEntry(ServiceContexts.java:322)
	at com.sun.corba.se.spi.servicecontext.ServiceContexts.writeServiceContextsInOrder(ServiceContexts.java:283)
	at com.sun.corba.se.spi.servicecontext.ServiceContexts.write(ServiceContexts.java:247)
	at com.sun.corba.se.impl.protocol.giopmsgheaders.ReplyMessage_1_2.write(ReplyMessage_1_2.java:175)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2199)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.createResponseHelper(CorbaMessageMediatorImpl.java:2162)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.createSystemExceptionResponse(CorbaMessageMediatorImpl.java:2087)
	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1871)
	... 19 more

I'll see if I can work up a very small standalone test app.

> Unfortunately, this isn't limited to just Orca.  :-(  Here's another way to
> reproduce the problem:
> 
> 1) Run SwingSet2
> 2) Run accerciser
> 3) Select SwingSet2 in accerciser
> 4) Go to accerciser's "Event Monitor" tab
> 5) Select "Selected application" as the source
> 5) Select just the "focus" event to monitor
> 6) Go back to SwingSet2 and press Alt+f, you'll get this stack trace:


I just did some more debugging, and it looks like this might be caused by asynchronous processing of events.  Originally, accerciser processed events synchronously, so it was always kind of my test bed for synchronous behavior independent of Orca.  But, I just discovered this:

http://svn.gnome.org/viewvc/accerciser/trunk/src/lib/accerciser/accerciser.py?view=diff&r1=432&r2=433

If I remove the "async=True" parameter from the call to pyatspi.Registry.start(), I cannot reproduce the stack trace.  With that knowledge, if I also force Orca to set settings.asyncMode=False, I also cannot reproduce the stack trace.

Now, it's a matter of figuring out more detail about this problem.  At first glance, it looks like pyatspi is doing the appropriate ref'ing to permit async processing to work, but this might need closer examination:

http://svn.gnome.org/viewvc/at-spi/trunk/pyatspi/event.py?view=annotate

To add more detail to this, I built/installed ORBit2, at-spi, orca, accerciser, and java-access-bridge from trunk, and I also made my /etc/orbitrc look like this:

ORBIIOPIPv4=1
#ORBLocalOnly=1
ORBLocalOnly=0
ORBIIOPIPName=127.0.0.1

I rebooted/retested and can still reproduce the problem.  So...it looks like something somewhere is still going amok.  In addition, I notice that in Orca, the code which retries on COMM_FAILURE (wrapped inside a pyatspi LookupError), will often succeed after a couple retries.  This makes me wonder if something somewhere in the Java CORBA code is temporarily hiccuping.

Created attachment 110578 [details]
A test script which can cause the crash

Only handle object:children-changed event and call getApplication method.

Though I set async=True, the applications still crash.

(In reply to comment #8)
> Though I set async=True, the applications still crash.

Nice work!  We finally have a small test app to reproduce the problem.  

If you set async=False, the stack trace should go away (do you notice this)?  In addition, I notice that if I replace the call to getApplication() with other calls, such as getState(), queryComponent(), and others, I can reproduce the stack trace.  But, this doesn't happen for *all* AT-SPI calls.  For example, getLocalizedRoleName doesn't seem to generate the trace.

Willie
Did you have your testing in Linux or Solairs? In Linux, it's sure if async=False, the application doesn't crash. But in Solaris, the
 java application sometimes will quit without any exception thrown out.

Do accerssier and orca require handling events asynchronously? Is it possible setting async=False always to solve this issue?

As I know, there is a group focusing on JAVA a11y in JAVA team. Could we ask them for help because this bug relates to JAVA a11y code.

(In reply to comment #10)
> Willie
> Did you have your testing in Linux or Solairs? In Linux, it's sure if
> async=False, the application doesn't crash. But in Solaris, the
>  java application sometimes will quit without any exception thrown out.

I'm testing on Solaris.  Note that I've never really seen a 'crash', but instead I only see a stack trace coming from the application.  In addition, related to this stack trace is that Orca is sometimes unable to process an event.

> Do accerssier and orca require handling events asynchronously? Is it possible
> setting async=False always to solve this issue?

Due to the event storms that come from applications, we need to process events asynchronously.

> As I know, there is a group focusing on JAVA a11y in JAVA team. Could we ask
> them for help because this bug relates to JAVA a11y code.

The last person I knew that was working on the Java Access Bridge for GNOME was you.  :-(

Will, I guess Jeff means those people who are doing the a11y implementation for java widgets, like gail for gtk+. Do we still have someone working in that area?

(In reply to comment #12)
> Will, I guess Jeff means those people who are doing the a11y implementation for
> java widgets, like gail for gtk+. Do we still have someone working in that
> area?

Jeff is listed as the maintainer of the java-access-bridge.  I'm not sure who maintains the actual a11y implementation inside the Java widgets themselves (e.g., who owns the a11y implementation of JLabel, for example).

I'm not sure intimate knowledge of the internal a11y implementation of Java a11y is actually needed here, however.  Based upon the analysis and testing so far, it really seems as though we might be able to rule that out and focus on the Java Access Bridge (JABG)  and how it communicates with external processes.  That requires more of a JABG/CORBA knowledge.

The fact that things are failing when events are handled asynchronously makes me wonder if the object ref counting is going awry, or if there is some queue processing thread that is causing a timeout to occur.

Willie,

In the test script, pyatspi receives the events via Java Acess Bridge, then it invokes event.source.getApplication which is not via Java Access Bridge, instead, it calls Java CORVA method implemented in JAVA A11Y implementation.

I looked at pyatspi code, in asynchronous working mode, all events will be put into a queue first. Then in an function added by gobject.idle_add, the events will be got out and handled. Java CORBA or Java Access Bridge doesn't know whether it is synchronized or asynchronize

Hi Jeff:

> In the test script, pyatspi receives the events via Java Acess Bridge, then it
> invokes event.source.getApplication which is not via Java Access Bridge,
> instead, it calls Java CORVA method implemented in JAVA A11Y implementation.

Yes - pyatspi will fallback to searching up the parent hierarchy if the getApplication method is not implemented.  I don't think this is the cause of the problem, however.  As I mention in comment #9, getState(), queryComponent(), and other calls also cause the stack trace.

> I looked at pyatspi code, in asynchronous working mode, all events will be put
> into a queue first. Then in an function added by gobject.idle_add, the events
> will be got out and handled. Java CORBA or Java Access Bridge doesn't know
> whether it is synchronized or asynchronize

Yes - exactly.  By putting events into a queue for later processing, they will be handled asynchronously.  If they are not put into a queue, but are instead handled directly in the event notification callback, they will be handled synchronously.  We need to handle things asynchronously because of the very large number of events we can get at any given time.  For example, opening a new window can flood us with events.

I don't think the problem is that the bridge needs to know whether or not the call is asynchronous.  Instead, the problem seems to be that something is going bad with the object state or CORBA state in the Java application side between the time the event is sent to Orca and the event source is examined by Orca.  

When Orca detects a failure while processing the event source, Orca has facilities to pause for a bit and then retry.  These seem to 'wake things up' in the Java application, but not always.  In addition, the extra time needed for retries results in noticeable responsiveness degradation for the Orca user.

So...for investigating this problem, I'm not sure where to dig first.  I think we need help from the Java CORBA folks to tell us what the stack trace means and what conditions cause it to happen.  Can you work with Ken on this?

Created attachment 110819 [details]
A simple java application which can be crashed

First I would say sorry because I made a mistake. In fact, all CORBA object implementations are in java-access-bridge code. In another word, java-access-bridge provides CORBA object which gets information of Java widgets via AccessibleContext corresponding with them.

When you move your mouse within some menus, a lot of object:children-changed:add and object:children-changed:remove events are produced. If I disable sending them, the bug can not be reproduced. I still need to dig deeply into the code before I can find the root cause.

Darren and Paraiag, maybe you can give me some suggestsions.

(In reply to comment #17)
> First I would say sorry because I made a mistake. In fact, all CORBA object
> implementations are in java-access-bridge code. In another word,
> java-access-bridge provides CORBA object which gets information of Java widgets
> via AccessibleContext corresponding with them.
> 
> When you move your mouse within some menus, a lot of
> object:children-changed:add and object:children-changed:remove events are
> produced. If I disable sending them, the bug can not be reproduced. I still
> need to dig deeply into the code before I can find the root cause.
> 
> Darren and Paraiag, maybe you can give me some suggestsions.

Jeff - this is interesting.  I wonder if we might be able to prevent a lot of this if the host_application of the event were populated.

(In reply to comment #18)
> Jeff - this is interesting.  I wonder if we might be able to prevent a lot of
> this if the host_application of the event were populated.

Sorry - I need to add more context.  If host_application were populated, we wouldn't need to run up the hierarchy from an event source in order to determine the application.  This would prevent a lot of roundtripping and also eliminate one of the cases that we've determined causes the issue to appear.

Jeff / Willie,

It's been a quite a while since I maintained the JABG code. 

But, I do remember issues on the Java side due to the way that CORBA and Swing are implemented. 

CORBA in Java is multi-threaded - you cannot guarantee what thread a call will arrive in on. Swing, on the other hand is very much single threaded - so all activity with an object should be limited to the single Swing/AWT thread - hence the existence of the SwingWorker class... 

What this means, is that in some cases, an even may occur on an object - this is dispatched to AT-SPI from the AWT Thread. The AT Client receives the event, and then queries the object for more information - this arrives in on a separate thread to the AWT Thread. At this point the original object that the event was dispatched on, may or may not exist - this can cause some issues. 

At the time I asked if the CORBA orb in Java could have a single-threaded model added to it, I don't know if this ever happened. Siimilarly, you can have difficulty accessing objects outside of the AWT thread due to a thing called the "treeLock" which essentially locks the whole of swing in the event thread.

I remember doing some work to try alleviate the risk, but it could never be fully mitigated without CORBA or Swing being fixed. 

Now, I have no idea what might have changed here to make things so unstable - certainly the Java App should never die - it never did when I experienced the problems, just you got some exceptions thrown now and again and the AT client might not get all the info it needed, but usually both sides didn't see any major crashes.

BUT - saying that, it's more likely for the AT client to crash if anything due to a null pointer return, etc.

On the Java side - it may be that the VM is unstable (is there a core file or hs_*.log file anywhere) - and not liking something we're doing... 

I don't know if this helps or not, but it should provide some background on issues that I experienced in the past... 

Created attachment 111552 [details] [review]
The patch adding EventDetail in Event

Will & Li, Please review the patch. Will, could you give a number of python lines to test the patch?

Created attachment 111659 [details]
Modified helloworld.py app to look at event.host_application.toolkitName

Here's a modified version of the helloworld.py attached earlier.  It merely does this:

        app = event.host_application
        print app.toolkitName

This seems to work fine with the patch from Jeff (thanks Jeff) and doesn't seem to cause the traceback in the Java app.  As a result, I think we can try to move forward with Orca to make it synchronously process events from Java applications.

Willie, doesn't it need to be modified for pyatspi when it knows the event comes from Java and should be handled immediately?

Is app.toolkitName also a CORBA invocation? If not, we also need one CORBA invocation in the test case.

(In reply to comment #23)
> Willie, doesn't it need to be modified for pyatspi when it knows the event
> comes from Java and should be handled immediately?

I suppose we could modify pyatspi to do this when pyatspi operates in async mode.
Orca itself, however, doesn't use pyatspi in async mode.  Instead, Orca is getting events synchronously from pyatspi, so Orca is the place where we can check to see if the toolkit is Java or not.  As a result, modifying pyatspi is not going to help Orca.  :-(

> Is app.toolkitName also a CORBA invocation? If not, we also need one CORBA
> invocation in the test case.

Yes, I believe looking at app.toolkitName results in a CORBA call.  We will do this when we receive the event, and it will be done synchronously.  As a result, I don't believe we will run into the asynchronous problem that is causing the stack trace.

The test in helloworld2.py is to make sure that host_application exists in the new event style being provided by your patch, and it seems to work nicely.  Thanks!

This patch, in conjunction with the Orca patch in bug #435585, seems to work nicely to help us prevent the stack trace.  :-)

The only thing is that this patch seems to output a lot of "Not Have assigend ed" lines, but I'm guessing you'd take those out before checking the code in?

Thanks for your work on this!

I'll remove the useless outputting lines and commit the patch to the trunk - gnome 2.23.

patch committed to branch 2.22 and trunk. Just now I released java-access-bridge 1.22.1.