GNOME Bugzilla – Bug 767074
Segfault in atspi_accessible_get_parent()
Last modified: 2021-07-05 10:45:40 UTC
Created attachment 328809 [details] backtrace 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->parent.app->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.
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
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.
Still a problem in Fedora 25 with Gnome 3.22. Orca regularly crashes particularly when closing Leafpad.
Howdy, 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
Not every time but often when closing Gedit this occurs,please test and confirm.
I have noticed that the bug happens in two situations, sometimes when I close gedit and sometimes when I switch to another window.
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.
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).
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.
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?
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! Nick
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: ./autogen.sh --prefix=/usr --sysconfdir=/etc \ --libexecdir=/usr/lib/at-spi2-core --disable-xevie make
Maybe it's too early to celebrate, but so far not received any crash. It seems the problem has been fixed.
I have not noticed a crash as yet, crossing fingers.
I am running for a week without crashes related to this bug. It seems that the problem was fixed.
Thanks for the testing. I'm going to assume that this is fixed. Please re-open if you see the crash again. master: 329ef2
This fix will be implemented in version 2.22? Thanks.
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/libpthread.so.0 #1 0x00007f9157d04fe0 in () at /usr/lib/libpthread.so.0 #2 0x00007f91532f1396 in atspi_accessible_get_parent () at /usr/lib/libatspi.so.0 #3 0x00007f91532f1639 in atspi_accessible_get_application () at /usr/lib/libatspi.so.0 #4 0x00007f915598e1c8 in ffi_call_unix64 () at /usr/lib/libffi.so.6 #5 0x00007f915598dc2a in ffi_call () at /usr/lib/libffi.so.6 #6 0x00007f915635697c in () at /usr/lib/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so #7 0x00007f9156358428 in () at /usr/lib/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so #8 0x00007f915634c1b9 in () at /usr/lib/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so #9 0x00007f91575ac84c in _PyObject_FastCallDict () at /usr/lib/libpython3.6m.so.1.0 #10 0x00007f9157557b86 in () at /usr/lib/libpython3.6m.so.1.0 #11 0x00007f9157513d77 in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.6m.so.1.0 #12 0x00007f9157557f47 in PyEval_EvalCodeEx () at /usr/lib/libpython3.6m.so.1.0 #13 0x00007f91575727d3 in () at /usr/lib/libpython3.6m.so.1.0 #14 0x00007f91575ad91b in PyObject_Call () at /usr/lib/libpython3.6m.so.1.0 #15 0x00007f915757a13e in () at /usr/lib/libpython3.6m.so.1.0 #16 0x00007f9157589e9d in _PyObject_GenericGetAttrWithDict () at /usr/lib/libpython3.6m.so.1.0 #17 0x00007f9157513df9 in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.6m.so.1.0 #18 0x00007f9157556291 in () at /usr/lib/libpython3.6m.so.1.0 #19 0x00007f915755778a in () at /usr/lib/libpython3.6m.so.1.0 #20 0x00007f9157557af3 in () at /usr/lib/libpython3.6m.so.1.0 #21 0x00007f9157514ba9 in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.6m.so.1.0 #22 0x00007f9157556f9a in _PyFunction_FastCallDict () at /usr/lib/libpython3.6m.so.1.0 #23 0x00007f91575aca4e in _PyObject_FastCallDict () at /usr/lib/libpython3.6m.so.1.0 #24 0x00007f91575ad852 in _PyObject_Call_Prepend () at /usr/lib/libpython3.6m.so.1.0 #25 0x00007f91575ad91b in PyObject_Call () at /usr/lib/libpython3.6m.so.1.0 #26 0x00007f91563543dc in () at /usr/lib/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so #27 0x00007f915598dfbf in ffi_closure_unix64_inner () at /usr/lib/libffi.so.6 #28 0x00007f915598e330 in ffi_closure_unix64 () at /usr/lib/libffi.so.6 #29 0x00007f9155bdb45a in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #30 0x00007f9155bdb810 in () at /usr/lib/libglib-2.0.so.0 #31 0x00007f9155bdbb32 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #32 0x00007f91532f7aec in atspi_event_main () at /usr/lib/libatspi.so.0 #33 0x00007f915598e1c8 in ffi_call_unix64 () at /usr/lib/libffi.so.6 #34 0x00007f915598dc2a in ffi_call () at /usr/lib/libffi.so.6 #35 0x00007f915635697c in () at /usr/lib/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so #36 0x00007f9156358428 in () at /usr/lib/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so #37 0x00007f91575ac84c in _PyObject_FastCallDict () at /usr/lib/libpython3.6m.so.1.0 #38 0x00007f9157557b86 in () at /usr/lib/libpython3.6m.so.1.0 #39 0x00007f9157513d77 in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.6m.so.1.0 #40 0x00007f9157556629 in () at /usr/lib/libpython3.6m.so.1.0 #41 0x00007f915755778a in () at /usr/lib/libpython3.6m.so.1.0 #42 0x00007f9157557af3 in () at /usr/lib/libpython3.6m.so.1.0 #43 0x00007f9157514ba9 in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.6m.so.1.0 #44 0x00007f915755753a in () at /usr/lib/libpython3.6m.so.1.0 #45 0x00007f9157557af3 in () at /usr/lib/libpython3.6m.so.1.0 #46 0x00007f9157513d77 in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.6m.so.1.0 #47 0x00007f9157555963 in () at /usr/lib/libpython3.6m.so.1.0 #48 0x00007f9157557af3 in () at /usr/lib/libpython3.6m.so.1.0 #49 0x00007f9157513d77 in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.6m.so.1.0 #50 0x00007f915755753a in () at /usr/lib/libpython3.6m.so.1.0 #51 0x00007f9157557af3 in () at /usr/lib/libpython3.6m.so.1.0 #52 0x00007f9157513d77 in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.6m.so.1.0 #53 0x00007f9157557f47 in PyEval_EvalCodeEx () at /usr/lib/libpython3.6m.so.1.0 #54 0x00007f9157513a5b in PyEval_EvalCode () at /usr/lib/libpython3.6m.so.1.0 #55 0x00007f91575dcdc2 in () at /usr/lib/libpython3.6m.so.1.0 #56 0x00007f91575df62d in PyRun_FileExFlags () at /usr/lib/libpython3.6m.so.1.0 #57 0x00007f91575df817 in PyRun_SimpleFileExFlags () at /usr/lib/libpython3.6m.so.1.0 #58 0x00007f91575d46f1 in Py_Main () at /usr/lib/libpython3.6m.so.1.0 #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.
Created attachment 348557 [details] back trace The trace was generated after I close gedit
Created attachment 348634 [details] back trace Apparently this crash was generated after I press alt+tab
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.
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.
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.
I finally saw this bug myself a little while ago. In the coredump, obj->parent.app 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.
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? Thanks.
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.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org 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 https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/ Thank you for your understanding and your help.