Bug 155449 - Launching Orca after Writer sometimes crashes Writer (stack trace provided) gtk3 a11y atkwrapper.cxx
Summary: Launching Orca after Writer sometimes crashes Writer (stack trace provided) g...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
Keywords: accessibility
Depends on:
Blocks: a11y-Linux
  Show dependency treegraph
Reported: 2023-05-23 12:01 UTC by Joanmarie Diggs
Modified: 2023-10-10 09:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs 2023-05-23 12:01:48 UTC
(See stack trace)

Steps to Reproduce:
1.Launch Writer
2.Launch Orca

Actual Results:
Writer sometimes crashes.

Expected Results:
Writer never crashes.

Reproducible: Sometimes

User Profile Reset: No

Additional Info:
Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0x00007f86d5c0d0cc in atk_object_get_index_in_parent (accessible=0x560eafda7fe0) at ../atk/atkobject.c:1065
Downloading source file /usr/src/debug/at-spi2-core-2.48.2-1.fc38.x86_64/redhat-linux-build/../atk/atkobject.c
1065      if (klass->get_index_in_parent)                                                                                                                                         
(gdb) bt
#0  0x00007f86d5c0d0cc in atk_object_get_index_in_parent (accessible=0x560eafda7fe0) at ../atk/atkobject.c:1065
#1  0x00007f86c82e5433 in wrapper_get_index_in_parent(AtkObject*) (atk_obj=0x560eafda9210)
    at /usr/src/debug/libreoffice-
#2  0x00007f86c79d6d2c in append_cache_item (obj=0x560eafda9210, data=0x7ffeda863e50) at ../atk-adaptor/adaptors/cache-adaptor.c:183
#3  0x00007f86d7ab65eb in g_hash_table_foreach (hash_table=0x560ea9b279d0 = {...}, func=0x7f86c79d6ef0 <append_accessible_hf>, user_data=0x7ffeda863e50) at ../glib/ghash.c:2175
#4  0x00007f86c79d3bfd in spi_cache_foreach (cache=<optimized out>, func=<optimized out>, data=<optimized out>) at ../atk-adaptor/accessible-cache.c:423
#5  0x00007f86c79dc089 in impl_GetItems (bus=<optimized out>, message=<optimized out>, user_data=<optimized out>) at ../atk-adaptor/adaptors/cache-adaptor.c:328
#6  0x00007f86c79df8b0 in handle_other
    (pathstr=0x560eaf5b7788 "/org/a11y/atspi/cache", member=0x560eaf5b77d8 "GetItems", iface=<optimized out>, path=0x560ea962da40, message=0x560eaf5ad0a0, bus=0x560eafdcf760)
    at ../droute/droute.c:558
#7  handle_message (bus=0x560eafdcf760, message=message@entry=0x560eaf5ad0a0, user_data=user_data@entry=0x560ea962da40) at ../droute/droute.c:605
#8  0x00007f86deaa22f4 in _dbus_object_tree_dispatch_and_unlock (found_object=<synthetic pointer>, message=<optimized out>, tree=0x560eafd02bf0)
    at ../../dbus/dbus-object-tree.c:1021
#9  dbus_connection_dispatch (connection=0x560eafdcf760) at ../../dbus/dbus-connection.c:4749
#10 dbus_connection_dispatch (connection=connection@entry=0x560eafdcf760) at ../../dbus/dbus-connection.c:4577
#11 0x00007f86c78336c1 in message_queue_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../atspi/atspi-gmain.c:89
#12 0x00007f86d7ad439c in g_main_dispatch (context=0x560ea896e7a0) at ../glib/gmain.c:3460
#13 g_main_context_dispatch (context=0x560ea896e7a0) at ../glib/gmain.c:4200
#14 0x00007f86d7b32438 in g_main_context_iterate.isra.0 (context=0x560ea896e7a0, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4276
#15 0x00007f86d7ad1a23 in g_main_context_iteration (context=0x560ea896e7a0, may_block=1) at ../glib/gmain.c:4343
#16 0x00007f86c82ffcec in GtkSalData::Yield(bool, bool) (bHandleAllCurrentEvents=<optimized out>, bWait=<optimized out>, this=0x560ea883c670)
    at /usr/src/debug/libreoffice-
#17 GtkInstance::DoYield(bool, bool) (this=<optimized out>, bWait=true, bHandleAllCurrentEvents=<optimized out>)
    at /usr/src/debug/libreoffice-
#18 0x00007f86db528dfc in ImplYield(bool, bool) (i_bWait=true, i_bAllEvents=false) at /usr/src/debug/libreoffice-
#19 0x00007f86db52fccd in Application::Execute() () at /usr/src/debug/libreoffice-
#20 0x00007f86ded5e46a in desktop::Desktop::Main() (this=0x7ffeda8646b0) at /usr/src/debug/libreoffice-
#21 0x00007f86db53bf9a in ImplSVMain() () at /usr/src/debug/libreoffice-
#22 0x00007f86db53c019 in SVMain() () at /usr/src/debug/libreoffice-
#23 0x00007f86ded771b8 in soffice_main() () at /usr/src/debug/libreoffice-
#24 0x0000560ea6fe30c7 in sal_main () at /usr/src/debug/libreoffice-
#25 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/libreoffice-
Comment 1 Dieter 2023-05-29 04:19:46 UTC
Joan Marie, thank you for the bug report. Just for clarification: Writer crashes immediately after launching Orca, correct? No further steps are needed? Could you please retest with a clean user profile? Thank you
Comment 2 Dieter 2023-05-29 04:23:39 UTC
Similar report is bug 154353.
Comment 3 Joanmarie Diggs 2023-09-15 14:17:56 UTC
*When* the crashes happen(ed?), yes it was immediate.

I just removed my profile and also tried safe mode. And from a few tries, I've not yet been able to reproduce the crash. Whether or not that means it's fixed <insert giant shrug here>. Aside from the fact that the crashes only happen(ed?) sometimes, my environment has changed (updated Fedora, updated AT-SPI2, updated Orca, etc.)

I'm somewhat curious as to how a profile, even a corrupted one, would cause the crash with the associated stack trace. Is there a short and simple explanation?

Regardless, feel free to close this. The next time I'm actively working on Orca's support for LO (which was the case when I encountered the crashes), I can re-open or re-file is the problem persists.
Comment 4 Joanmarie Diggs 2023-10-10 08:50:29 UTC
Turns out this still happens.
Comment 5 Michael Weghorn 2023-10-10 09:13:23 UTC
Setting to NEW, I've at least seen this in the past.