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 698095 - ATK Wrapper makes java applications crash
ATK Wrapper makes java applications crash
Status: VERIFIED FIXED
Product: java-atk-wrapper
Classification: Applications
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: java-atk-wrapper maintainer(s)
java-atk-wrapper maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-04-15 23:05 UTC by Samuel Thibault
Modified: 2015-06-06 08:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to fix bug (8.17 KB, patch)
2015-06-02 19:49 UTC, Magdalen Berns (irc magpie)
committed Details | Review
missed a couple in jawutil (1.32 KB, patch)
2015-06-03 15:46 UTC, Magdalen Berns (irc magpie)
committed Details | Review

Description Samuel Thibault 2013-04-15 23:05:24 UTC
Hello,

Openjdk is disabling accessibility by default because the atk wrapper is making applications crash. See notably 

https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/935296

This is pretty bad, because this prevents distributions from being accessible by default.

It seems to all boil down to a single issue: java-atk-wrapper uses threads, and thus uses XInitThreads to attempt to initialize a thread-safe libX11, but whenever the application initializes X11 before java-atk-wrapper gets to call XInitThreads, libX11 is kept initialized in a non-threadsafe way, resulting into all kinds of races and odd issues.

I'm not sure whether the JNI provides any way to be sure of calling XInitThreads before anything else in the application initializes libX11. The safest way would of course be that java-atk-wrapper does not use threads at all, or at least perform all X11 operations in the main thread.

Samuel
Comment 1 André Klapper 2013-08-14 10:03:50 UTC
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
Comment 2 Samuel Thibault 2015-02-08 19:42:26 UTC
Which kind of information is missing?  There was no question asked to this bug report.
Comment 3 André Klapper 2015-02-27 16:56:14 UTC
[Moving at-spi/java-atk-wrapper bugs to separate product. See bug 740075]
Comment 4 Magdalen Berns (irc magpie) 2015-04-13 08:55:20 UTC
(In reply to Samuel Thibault from comment #2)
> Which kind of information is missing?  There was no question asked to this
> bug report.

Thanks for getting back to me about this Samuel. Sorry, for not making the NEEDINFO clear sooner.

Essentially, I was not ever able to recreate the issue in your report, so I just wanted to check what version you are having trouble with. The whole approach to initialisation and threading has been updated fairly substantially since this bug was first filed, so I am hoping the changes may have dealt with your issue (hopefully without replacing it with any new issue).

Latest version is at: https://git.gnome.org/browse/java-atk-wrapper/

Thanks again.
Comment 5 Samuel Thibault 2015-05-01 20:51:42 UTC
I have now tried version 0.32.92, running the arduino application, getting:

(java:11546): Gdk-CRITICAL **: IA__gdk_threads_set_lock_functions: assertion 'gdk_threads_lock == NULL && gdk_threads_unlock == NULL' failed

(java:11546): GLib-GObject-WARNING **: cannot register existing type 'JawImpl_2'

(java:11546): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

(java:11546): GLib-GObject-WARNING **: invalid cast from 'JawImpl_2' to '<invalid>'
etc. and eventually crash

Commenting assistive_technologies=org.GNOME.Accessibility.AtkWrapper makes the application work fine (and the atk wrapper not get loaded of course).
Comment 6 Magdalen Berns (irc magpie) 2015-05-30 01:30:39 UTC
These warnings seem to be addressed with attachment 304294 [details] [review] for bug 750128.

The stack I have for the crash itself:

  • #0 jaw_action_get_keybinding
    at jawaction.c line 233
  • #1 impl_get_keybinding
    at action-adaptor.c line 140
  • #2 handle_message
    at droute.c line 553
  • #3 handle_message
    at droute.c line 600
  • #4 _dbus_object_tree_dispatch_and_unlock
    at dbus-object-tree.c line 1018
  • #5 dbus_connection_dispatch
    at dbus-connection.c line 4718
  • #6 message_queue_dispatch
    at atspi-gmain.c line 89
  • #7 g_main_context_dispatch
    at gmain.c line 3122
  • #8 g_main_context_dispatch
    at gmain.c line 3737
  • #9 g_main_context_iterate
    at gmain.c line 3808
  • #10 g_main_loop_run
    at gmain.c line 4002
  • #11 jni_loop_callback
    at AtkWrapper.c line 102
  • #12 g_thread_proxy
    at gthread.c line 764
  • #13 start_thread
    at pthread_create.c line 333
  • #14 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 109


Is that consistent with what you're seeing?
Comment 7 Samuel Thibault 2015-05-30 10:00:03 UTC
It's a bit different here, but that's the idea, yes:

  • #0 jaw_component_get_extents
    at jawcomponent.c line 211
  • #1 atk_component_get_extents
  • #2 impl_GetExtents
    at component-adaptor.c line 107
  • #3 handle_message
    at droute.c line 553
  • #4 handle_message
    at droute.c line 600
  • #5 _dbus_object_tree_dispatch_and_unlock
    at ../../dbus/dbus-object-tree.c line 1018
  • #6 dbus_connection_dispatch
    at ../../dbus/dbus-connection.c line 4718
  • #7 message_queue_dispatch
    at atspi-gmain.c line 89
  • #8 g_main_context_dispatch
    at /build/glib2.0-etimD8/glib2.0-2.44.0/./glib/gmain.c line 3122
  • #9 g_main_context_dispatch
    at /build/glib2.0-etimD8/glib2.0-2.44.0/./glib/gmain.c line 3737
  • #10 g_main_context_iterate
    at /build/glib2.0-etimD8/glib2.0-2.44.0/./glib/gmain.c line 3808
  • #11 g_main_loop_run
    at /build/glib2.0-etimD8/glib2.0-2.44.0/./glib/gmain.c line 4002
  • #12 jni_loop_callback
    at AtkWrapper.c line 103
  • #13 g_thread_proxy
    at /build/glib2.0-etimD8/glib2.0-2.44.0/./glib/gthread.c line 764
  • #14 start_thread
    at pthread_create.c line 309
  • #15 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 111

Comment 8 Magdalen Berns (irc magpie) 2015-06-02 19:49:53 UTC
Created attachment 304453 [details] [review]
patch to fix bug
Comment 9 Magdalen Berns (irc magpie) 2015-06-02 19:51:21 UTC
I think this can be closed now as it seems to have addressed the crash for me, but feel free to re-open if you are still having the same problem.
Comment 10 Magdalen Berns (irc magpie) 2015-06-03 15:46:57 UTC
Created attachment 304529 [details] [review]
missed a couple in jawutil

crash doesn't seem to be caused without this patch but I have amended the g_hash_table_lookup arguments just for the sake of it.
Comment 11 Samuel Thibault 2015-06-06 08:44:31 UTC
Yes, with these patches applied, I don't get the crash any more.