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 767074 - Segfault in atspi_accessible_get_parent()
Segfault in atspi_accessible_get_parent()
Product: at-spi
Classification: Platform
Component: at-spi2-core
Other Linux
: Normal normal
: ---
Assigned To: At-spi maintainer(s)
At-spi maintainer(s)
Depends on:
Reported: 2016-05-31 14:59 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2021-07-05 10:45 UTC
See Also:
GNOME target: ---
GNOME version: ---

backtrace (11.99 KB, text/plain)
2016-05-31 14:59 UTC, Joanmarie Diggs (IRC: joanie)
back trace (5.34 KB, text/x-log)
2017-03-23 10:52 UTC, Jose Vilmar Estacio de Souza
back trace (1.22 KB, text/x-log)
2017-03-24 09:16 UTC, Jose Vilmar Estacio de Souza
a new back trace after close gedit (5.34 KB, text/x-log)
2017-03-28 09:43 UTC, Jose Vilmar Estacio de Souza

Description Joanmarie Diggs (IRC: joanie) 2016-05-31 14:59:33 UTC
Created attachment 328809 [details]

Orca users have reported that Orca sometimes hangs when apps are quit. I cannot reproduce this reliably yet, but I'm attaching the backtrace from one case where I could. I'll do my best to work around this in Orca, but I do not *think* Orca is causing this. For instance, given the segfault here:

Thread 1 "orca" received signal SIGSEGV, Segmentation fault.
0x00007f18fdd501d6 in atspi_accessible_get_parent (obj=obj@entry=0x5591534dc220, error=error@entry=0x0) at atspi-accessible.c:276
276         message = dbus_message_new_method_call (obj->>bus_name,

The Orca call was a debugging line:
    data = "%s (%s,%s,%s) from %s" % \
           (e.source, e.detail1, e.detail2, e.any_data, e.host_application)

atspi_accessible_get_application() calls atspi_accessible_get_parent() which segfaults.
Comment 1 Mike Gorse 2016-06-01 19:04:11 UTC
From IRC:

<joanie> the way I repro it, which is sad
<joanie> is I launch a bunch of apps
<joanie> and pound on them as fast as I can
<joanie> lots of going into gnome-shell
<joanie> lots of alt+tabbing
<joanie> lots F4ing
<joanie> lots of f1ing, typing a few letters (e.g. fire for firefox)
<joanie> then hammering through the app menues (in the case of fireefox)
<joanie> as quickly as I can to generate a bunch of events
<joanie> and quitting before they can all be processed
<joanie> then I pause and wait to see if orca catches up
<joanie> after a period of silence I use gdb to attach to the process
> quitting orca? or quitting firefox / other apps?
<joanie> leave orca running
Comment 2 Mike Gorse 2016-06-07 13:49:59 UTC
Can you reproduce this with the last cor gnome-3-20? I'm having trouble reproducing, and I'm wonderin if it is fixed with the last commit, though I think it more likely that I'm just not doing the right thing to reproduce it.
Comment 3 Nick Wood 2016-12-28 15:54:13 UTC
Still a problem in Fedora 25 with Gnome 3.22. Orca regularly crashes particularly when closing Leafpad.
Comment 4 chris 2017-01-16 19:46:45 UTC

it happens really often here. mostly when switching windows.
can i help debugging this somehow?

using latest archlinux with most current  gnome/ orca/ ATK/ AT-SPI2

currently  3.22.x

cheers chrys
Comment 5 Rob Whyte 2017-01-19 12:30:59 UTC
Not every time but often when closing Gedit this occurs,please test and confirm.
Comment 6 Jose Vilmar Estacio de Souza 2017-01-19 13:10:40 UTC
    I have noticed that the bug happens in two situations, sometimes when I close gedit and sometimes when I switch to another window.
Comment 7 Nick Wood 2017-01-19 14:27:39 UTC
For me it happens mostly when closing an application. I rarely see it when switching from one app to another.  I don't use Gedit but instead use Leafpad, and it triggers the bug and crashes Orca maybe 75% of the time when I close it.
Comment 8 Mike Gorse 2017-01-24 18:18:21 UTC
I haven't been able to reproduce this so far, and I'm somewhat mystified by it--presumably an object is being unrefed somewhere where it shouldn't, or not being refed when it should.
Is starting and immediately closing gedit or leafpad enough to reproduce the bug, or does the crash only happen if you've done a bit of work inside the application?

Maybe running orca under valgrind would help (note that valgrind greatly slows down the application running inside of it).
Comment 9 Jose Vilmar Estacio de Souza 2017-01-24 19:12:55 UTC
For me the crash happen if I've done a bit of work.
I usually keep several terminal windows open where I run some applications and  switch from one to the other very often.

From time to time orca is mute and after some period I discover a new memory dump in my machine.

Sometimes, after use gedit for a while and quit gedit, orca is mute and I find another core dump.
Comment 10 Mike Gorse 2017-01-25 00:14:10 UTC
I just pushed a change that I'm hoping might help, though I still haven't been able to reproduce, and, regardless, there may be a deeper problem that I haven't fixed. For anyone pulling from master, could you please test and let me know if you still see this crash?
Comment 11 Nick Wood 2017-01-25 08:09:19 UTC
Happy to test, but have never built Atspi from source before.  I do run Orca from master, so is it pretty much the same? I.e. clone, make and make install, or are there any complications along the way? Also will Orca automatically use the locally build version or will I need to tweak something?

Thanks and apologies for having to ask!

Comment 12 Jose Vilmar Estacio de Souza 2017-01-25 08:51:58 UTC
In my arch box I recreated the package using git but I don't know how to do the same using fedora.
The steps used to recompile in arch are:
  ./ --prefix=/usr --sysconfdir=/etc \
    --libexecdir=/usr/lib/at-spi2-core --disable-xevie
Comment 13 Jose Vilmar Estacio de Souza 2017-01-27 19:58:55 UTC
Maybe it's too early to celebrate, but so far not received any crash.
It seems the problem has been fixed.
Comment 14 Rob Whyte 2017-01-30 00:07:02 UTC
I have not noticed a crash as yet, crossing fingers.
Comment 15 Jose Vilmar Estacio de Souza 2017-02-01 11:25:13 UTC
I am running for a week without crashes related to this bug.
It seems that the problem was fixed.
Comment 16 Mike Gorse 2017-02-01 18:06:05 UTC
Thanks for the testing. I'm going to assume that this is fixed.
Please re-open if you see the crash again.

master: 329ef2
Comment 17 Jose Vilmar Estacio de Souza 2017-02-03 11:40:09 UTC
This fix will be implemented in version 2.22?
Comment 18 Jose Vilmar Estacio de Souza 2017-03-23 10:49:39 UTC
Since Monday 20, I am experiencing some lockups in my machine and some dumps are generated.
coredumpctl gdb presents the following information:

Core was generated by `/usr/bin/python /data/software/orca3/arch2/bin/orca --replace'.

Recently the atk version was updated to 2.24.0 and coincidentally, problems started shortly thereafter.

The bt command in gdb reports the following:

bt full #0 0x00007f9157d04ea0 in raise () at /usr/lib/ #1 0x00007f9157d04fe0 in () at /usr/lib/ #2 0x00007f91532f1396 in atspi_accessible_get_parent () at /usr/lib/ #3 0x00007f91532f1639 in atspi_accessible_get_application () at /usr/lib/ #4 0x00007f915598e1c8 in ffi_call_unix64 () at /usr/lib/ #5 0x00007f915598dc2a in ffi_call () at /usr/lib/ #6 0x00007f915635697c in () at /usr/lib/python3.6/site-packages/gi/ #7 0x00007f9156358428 in () at /usr/lib/python3.6/site-packages/gi/ #8 0x00007f915634c1b9 in () at /usr/lib/python3.6/site-packages/gi/ #9 0x00007f91575ac84c in _PyObject_FastCallDict () at /usr/lib/ #10 0x00007f9157557b86 in () at /usr/lib/ #11 0x00007f9157513d77 in _PyEval_EvalFrameDefault () at /usr/lib/ #12 0x00007f9157557f47 in PyEval_EvalCodeEx () at /usr/lib/ #13 0x00007f91575727d3 in () at /usr/lib/ #14 0x00007f91575ad91b in PyObject_Call () at /usr/lib/ #15 0x00007f915757a13e in () at /usr/lib/ #16 0x00007f9157589e9d in _PyObject_GenericGetAttrWithDict () at /usr/lib/ #17 0x00007f9157513df9 in _PyEval_EvalFrameDefault () at /usr/lib/ #18 0x00007f9157556291 in () at /usr/lib/ #19 0x00007f915755778a in () at /usr/lib/ #20 0x00007f9157557af3 in () at /usr/lib/ #21 0x00007f9157514ba9 in _PyEval_EvalFrameDefault () at /usr/lib/ #22 0x00007f9157556f9a in _PyFunction_FastCallDict () at /usr/lib/ #23 0x00007f91575aca4e in _PyObject_FastCallDict () at /usr/lib/ #24 0x00007f91575ad852 in _PyObject_Call_Prepend () at /usr/lib/ #25 0x00007f91575ad91b in PyObject_Call () at /usr/lib/ #26 0x00007f91563543dc in () at /usr/lib/python3.6/site-packages/gi/ #27 0x00007f915598dfbf in ffi_closure_unix64_inner () at /usr/lib/ #28 0x00007f915598e330 in ffi_closure_unix64 () at /usr/lib/ #29 0x00007f9155bdb45a in g_main_context_dispatch () at /usr/lib/ #30 0x00007f9155bdb810 in () at /usr/lib/ #31 0x00007f9155bdbb32 in g_main_loop_run () at /usr/lib/ #32 0x00007f91532f7aec in atspi_event_main () at /usr/lib/ #33 0x00007f915598e1c8 in ffi_call_unix64 () at /usr/lib/ #34 0x00007f915598dc2a in ffi_call () at /usr/lib/ #35 0x00007f915635697c in () at /usr/lib/python3.6/site-packages/gi/ #36 0x00007f9156358428 in () at /usr/lib/python3.6/site-packages/gi/ #37 0x00007f91575ac84c in _PyObject_FastCallDict () at /usr/lib/ #38 0x00007f9157557b86 in () at /usr/lib/ #39 0x00007f9157513d77 in _PyEval_EvalFrameDefault () at /usr/lib/ #40 0x00007f9157556629 in () at /usr/lib/ #41 0x00007f915755778a in () at /usr/lib/ #42 0x00007f9157557af3 in () at /usr/lib/ #43 0x00007f9157514ba9 in _PyEval_EvalFrameDefault () at /usr/lib/ #44 0x00007f915755753a in () at /usr/lib/ #45 0x00007f9157557af3 in () at /usr/lib/ #46 0x00007f9157513d77 in _PyEval_EvalFrameDefault () at /usr/lib/ #47 0x00007f9157555963 in () at /usr/lib/ #48 0x00007f9157557af3 in () at /usr/lib/ #49 0x00007f9157513d77 in _PyEval_EvalFrameDefault () at /usr/lib/ #50 0x00007f915755753a in () at /usr/lib/ #51 0x00007f9157557af3 in () at /usr/lib/ #52 0x00007f9157513d77 in _PyEval_EvalFrameDefault () at /usr/lib/ #53 0x00007f9157557f47 in PyEval_EvalCodeEx () at /usr/lib/ #54 0x00007f9157513a5b in PyEval_EvalCode () at /usr/lib/ #55 0x00007f91575dcdc2 in () at /usr/lib/ #56 0x00007f91575df62d in PyRun_FileExFlags () at /usr/lib/ #57 0x00007f91575df817 in PyRun_SimpleFileExFlags () at /usr/lib/ #58 0x00007f91575d46f1 in Py_Main () at /usr/lib/ #59 0x0000000000400a5d in main ()

I tried to compile at-spi2-core with debug symbols and will attach a trace as soon a new dump is generated.
Comment 19 Jose Vilmar Estacio de Souza 2017-03-23 10:52:50 UTC
Created attachment 348557 [details]
back trace

The trace was generated after I close gedit
Comment 20 Jose Vilmar Estacio de Souza 2017-03-24 09:16:43 UTC
Created attachment 348634 [details]
back trace

Apparently this crash was generated after I press alt+tab
Comment 21 Jose Vilmar Estacio de Souza 2017-03-26 12:18:46 UTC
I know this will sound weird, but it seems like the problem happens
more often when I'm using low-quality internet access. For example a connection that drops quite frequently.
Comment 22 Jose Vilmar Estacio de Souza 2017-03-28 09:43:50 UTC
Created attachment 348872 [details]
a new back trace after close gedit

The crash happened as soon as I closed gedit.
I updated at-spi2-core and at-spi2-atk to latest version from git.
Comment 23 Michał Zegan 2017-04-17 14:41:18 UTC
I have at-spi 2.22.0, atk 2.24.0, orca from git updated around a week ago, and this bug is happening to me.
Comment 24 Mike Gorse 2017-05-09 00:15:40 UTC
I finally saw this bug myself a little while ago.
In the coredump, obj-> appeared to be set to NULL, which is mysterious to me, since, in theory, that code path should not be executed in that case, unless somehow the object is being modified in another thread while atspi_accessible_get_parent is being called.

I just pushed a change to master and gnome-3-24 that moves the NULL check. I'll be curious as to whether this helps, for people running into this bug on a regular basis, although, in theory, I don't see how it would make a difference. Regardless, it might make the code a bit more robust.
Comment 25 Jose Vilmar Estacio de Souza 2017-06-16 21:12:31 UTC
This bug is still present in my environment. I'm thinking of compiling
at-spi2-core from git to see if anything changes.

Would anyone have another suggestion?
Comment 26 Jose Vilmar Estacio de Souza 2017-06-26 14:22:02 UTC
I decided to go ahead and compile and install the master version of
the at-spi2-core present in git.
I did this in 2017-06-16 and since then problems related to this bug
have disappeared, at least so far.

I didn't test using the latest version present in git, only the version present in the commit c475b5c753df3130e29df40278fe305246a424e2.
Comment 27 GNOME Infrastructure Team 2021-07-05 10:45:40 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
and create a new ticket at

Thank you for your understanding and your help.