GNOME Bugzilla – Bug 742157
SIGSEGV fatal error when executing SwingSet2
Last modified: 2015-02-27 16:57:18 UTC
See attachment for more info.[1] Also see https://bugzilla.gnome.org/show_bug.cgi?id=741062#c36 [1] https://bug741062.bugzilla-attachments.gnome.org/attachment.cgi?id=293495
Created attachment 293577 [details] [review] Patch to fix issue It seems like the implementation of the update to g_mutex_init and g_cond_init was not correct this has been responsible for the issue. There is still an issue with SwingSet2 but now it's hanging so it's possible to get a trace with gdb and figure out what is triggering the issue there. I will paste that in a bit.
The terminal error is (process:20961): GModule-CRITICAL **: g_module_symbol: assertion 'module != NULL' failed (process:20961): GModule-CRITICAL **: g_module_close: assertion 'module != NULL' failed
Created attachment 293579 [details] [review] Patch to address actually problem
(gdb) thread apply all bt
+ Trace 234488
Thread 12 (Thread 0x7fa1682db700 (LWP 24836))
Created attachment 293580 [details] [review] Patch to fix error
Reopening as removing the g_cond_wait call only means that nothing is waiting and the a11y wrapper is bypassed.
Created attachment 293601 [details] [review] Patch to address problem
Ok I believe I have got to the bottom of this. It seems that there is an openJDK patch, "openjdk-accessibility" which allows the accessibility wrapper work with OpenJDK. Problem: Installing that installing that also installs the non-development version of the wrapper which makes testing of the development version a problem. Solution find the source code for this patch from *somewhere*, install it and potentially figure out how to not need that so that the wrapper can be self contained. I'm going to change the severity of this to "blocker" since testing relies on it being resolved.
Created attachment 293686 [details] [review] patch to fix error Ok on further investigation it turns out the issue mentioned in comment 8 was not the cause the problem. This one line patch fixes it.
java -jar SwingSet2.jar ** (java:8629): CRITICAL **: atk_object_get_role: assertion 'ATK_IS_OBJECT (accessible)' failed ** (java:8629): CRITICAL **: atk_object_get_role: assertion 'ATK_IS_OBJECT (accessible)' failed (java:8629): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed ** (java:8629): CRITICAL **: atk_object_get_name: assertion 'ATK_IS_OBJECT (accessible)' failed (java:8629): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (java:8629): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed ** (java:8629): CRITICAL **: atk_object_get_name: assertion 'ATK_IS_OBJECT (accessible)' failed (java:8629): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (java:8629): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed (java:8629): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (java:8629): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed (java:8629): GLib-GObject-WARNING **: invalid (NULL) pointer instance (java:8629): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed ** (java:8629): CRITICAL **: atk_object_ref_state_set: assertion 'ATK_IS_OBJECT (accessible)' failed (java:8629): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fa0628e787d, pid=8629, tid=140325708363520 # # JRE version: OpenJDK Runtime Environment (8.0_25-b18) (build 1.8.0_25-b18) # Java VM: OpenJDK 64-Bit Server VM (25.25-b02 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libatk-wrapper.so.1.0.20+0x987d] jaw_action_get_keybinding+0x2d # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /data/Downloads/hs_err_pid8629.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Aborted (core dumped)
Created attachment 293811 [details] file generated by error reported in comment #10
(In reply to comment #11) > Created an attachment (id=293811) [details] > file generated by error reported in comment #10 Did you run sudo make distclean before re-installing?
(In reply to comment #12) > > Did you run > > sudo make distclean > > before re-installing? The commands that I run to compile and install are the following: make uninstall&& make distclean&& git clean -f -d -X&& ./autogen.sh --prefix=/usr&& make&& make install They are present in a script and I run the script with sudo.
Can you upload the file produced: i.e. /data/Downloads/hs_err_pid8629.log
Also, just to make sure: Did you also run SwingSet as root? because if so, you should not be doing that.
(In reply to comment #15) > Also, just to make sure: Did you also run SwingSet as root? because if so, you > should not be doing that. No, run as normal user.
(In reply to comment #14) > Can you upload the file produced: i.e. /data/Downloads/hs_err_pid8629.log Unless I am wrong, I updated in comment #11.
(In reply to comment #17) > (In reply to comment #14) > > Can you upload the file produced: i.e. /data/Downloads/hs_err_pid8629.log > > Unless I am wrong, I updated in comment #11. Sorry, I missed that. I am not able to recreate this bug with SwingSet though I do seem to get a SIGEV with notepad though the log looks, a little different on that. I am just wondering, does it get triggered by a particular event or is it reproducible for you every time you literally just run the SwingSet program?
(In reply to comment #18) > Sorry, I missed that. I am not able to recreate this bug with SwingSet though I > do seem to get a SIGEV with notepad though the log looks, a little different on > that. > > I am just wondering, does it get triggered by a particular event or is it > reproducible for you every time you literally just run the SwingSet program? Every time I run the SwingSet program I receive the SIGSEGV error. Seems that the screen appears because I can hear orca announce something like toggle button but after that the program aborts. Did you try run the SwingSet program with orca active? I think that the problem can be reproduced if orca is active. If I execute the SwingSet program without orca, I do not receive the SIGSEGV error.
(In reply to comment #19) > (In reply to comment #18) > > Sorry, I missed that. I am not able to recreate this bug with SwingSet though I > > do seem to get a SIGEV with notepad though the log looks, a little different on > > that. > > > > I am just wondering, does it get triggered by a particular event or is it > > reproducible for you every time you literally just run the SwingSet program? > > > Every time I run the SwingSet program I receive the SIGSEGV error. Seems that > the screen appears because I can hear orca announce something like toggle > button but after that the program aborts. > > Did you try run the SwingSet program with orca active? > I think that the problem can be reproduced if orca is active. > If I execute the SwingSet program without orca, I do not receive the SIGSEGV > error. Thanks for the additional information. I am able to recreate this bug now and can confirm that it is a different SIGSEGV bug to the one originally reported in comment 0. It is not triggered when orca is activated but seems to occur when a focused widget is clicked on. I will update you with a new bug report and cc you. For now, I will close this bug.
[Moving at-spi/java-atk-wrapper bugs to separate product. See bug 740075]