After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 766774 - Avoid calling getAccessibleContext from the loop thread
Avoid calling getAccessibleContext from the loop thread
Status: RESOLVED FIXED
Product: java-atk-wrapper
Classification: Applications
Component: general
0.33.x
Other Linux
: Normal normal
: ---
Assigned To: java-atk-wrapper maintainer(s)
java-atk-wrapper maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-05-22 15:36 UTC by Samuel Thibault
Modified: 2019-05-01 22:06 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Add a mutex for the object hash table (4.51 KB, patch)
2016-05-22 15:37 UTC, Samuel Thibault 		none Details | Review
Avoid unexpected threaded call to application callbacks (23.02 KB, patch)
2016-05-22 15:37 UTC, Samuel Thibault 		none Details | Review
Avoid unexpected threaded call to application callbacks (23.26 KB, patch)
2018-02-17 17:26 UTC, Samuel Thibault 		none Details | Review

Description Samuel Thibault 2016-05-22 15:36:39 UTC 
Hello,

We have seen threading issues in josm, because getCurrentAccessibleContext ends up being called frop the loop thread, which leads to an unexpected call to application methods from the loop thread, for which the application does not implement synchronization, since normally there is no concurrency there. For instance:

java.lang.NullPointerException
    at org.openstreetmap.josm.gui.dialogs.relation.sort.WayConnectionTypeCalculator.Fixthread(WayConnectionTypeCalculator.java:36)
    at org.openstreetmap.josm.gui.dialogs.relation.sort.WayConnectionTypeCalculator.updateLinks(WayConnectionTypeCalculator.java:43)
    at org.openstreetmap.josm.gui.dialogs.relation.MemberTableModel.getWayConnection(MemberTableModel.java:761)
    at org.openstreetmap.josm.gui.dialogs.relation.MemberTableModel.getValueAt(MemberTableModel.java:219)
    at javax.swing.JTable.getValueAt(JTable.java:2717)
    at javax.swing.JTable$AccessibleJTable$AccessibleJTableCell.getCurrentAccessibleContext(JTable.java:7950)
    at javax.swing.JTable$AccessibleJTable$AccessibleJTableCell.addPropertyChangeListener(JTable.java:8189)
    at org.GNOME.Accessibility.AtkWrapper.registerPropertyChangeListener(AtkWrapper.java:625)

Here, getValueAt was overloaded by the application, and thus the mere call to getCurrentAccessibleContext ended up expectedly calling application code.

In the proposed patch, we call jaw_impl_get_instance from the java accessibility callback, instead of delaying that to the callback in the atk glib loop.

This however brings concurrent access to the object hash table. This can be simply protected by a mutex, as shown in the other submitted patch.

Samuel
Comment 1 Samuel Thibault 2016-05-22 15:37:17 UTC 
Created attachment 328347 [details] [review]
Add a mutex for the object hash table
Comment 2 Samuel Thibault 2016-05-22 15:37:43 UTC 
Created attachment 328348 [details] [review]
Avoid unexpected threaded call to application callbacks
Comment 3 Samuel Thibault 2018-02-17 17:26:28 UTC 
Created attachment 368479 [details] [review]
Avoid unexpected threaded call to application callbacks

Here is an updated version, with proper printfs.
Comment 4 Samuel Thibault 2019-05-01 22:06:38 UTC 
Fixed by e7588805b89552a6154356cc013927484f7bf0b6 ("Call jaw_impl_get_instance from the application thread")