Bug Hunting Session
Bug 70465 - [a11y] with Assistive Technology Tools enabled building "Expert Config" tool is slow and resource intensive
Summary: [a11y] with Assistive Technology Tools enabled building "Expert Config" tool ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: Other All
: highest normal
Assignee: Mihály Palenik
URL:
Whiteboard: target:4.2.0 target:4.3.0
Keywords:
: 73721 74350 (view as bug list)
Depends on:
Blocks: a11y mab4.3
  Show dependency treegraph
 
Reported: 2013-10-14 20:03 UTC by V Stuart Foote
Modified: 2016-10-25 19:44 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
error pop-up on crash when JRE is enabled with Java Access Bridge (5.59 KB, image/png)
2013-10-18 21:34 UTC, V Stuart Foote
Details
screen capture of locked up LODev 420 session on Fedora 19 GNOME DE with ORCA active (219.16 KB, image/png)
2013-10-19 19:20 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2013-10-14 20:03:56 UTC
On Windows 7 sp1, 64-bit

A msiexec.exe /A Administrative install of:

Version: 4.2.0.0.alpha0+
Build ID: 4badcfda55996891d99b1f0a8cc47028acd1c0c1
TinderBox: Win-x86@39, Branch:master, Time: 2013-10-14_04:13:30

Simply launching Expert Configuration on recent TB builds of Master will lock up LibreOffice Dev builds on Windows platforms.  System CPU use rises to 50-60% and will not clear.

Frame "Options - LibreOfficeDev - User Data" opens but shortly receives a (Not responding) tag.

Have to kill the process to be able to exit.
Comment 1 V Stuart Foote 2013-10-14 20:10:08 UTC
Efe,

This 2013-10-14 build TB 39 build of master was not first occurrence. In fact I've seen this lock up for at least a month on Windows /A installs, just getting around to a bit of QA work and reporting it in.

Stuart
Comment 2 Efe Gürkan YALAMAN 2013-10-18 19:54:58 UTC
Hi Stuart,

Thanks for the report.

I installed this build with Florian Reisinger's tool on Windows 7 SP1 64-Bit.

Version: 4.2.0.0.alpha0+
Build ID: cc2a405915e82c4b332dd25457f76704dc536d7f
TinderBox: Win-x86@39, Branch:master, Time: 2013-10-15_15:51:52

I couldn't reproduce the bug. I am not a Windows expert and didn't work on Windows on this project. So lacking a little of knowledge here. Is there any difference of installations.

But I can say a few words about what is the situation you have here. During the page load we have a slow part of code which prints the output to the listbox you see. This takes about 6 seconds on debug build on Linux. I think the this part cause the lock up on your computer.

I will try to reproduce that on my old machine too. Any information would appreciated.

Efe Gürkan
Comment 3 Efe Gürkan YALAMAN 2013-10-18 20:10:35 UTC
Hi again,

Tested with the same build on my old laptop and couldn't reproduce it on that too.

Best,
Comment 4 V Stuart Foote 2013-10-18 21:34:09 UTC
Created attachment 87839 [details]
error pop-up on crash when JRE is enabled with Java Access Bridge

Efe,

OK went back and worked with the 2013-10-14 TB 39 build some more.

I normally will work with a JRE with Java Access Bridge enabled (i.e. jabswitch -enable) and normally have the Tools --> Options --> Accessibility --> Support Assistive Technology enabled.

Watching in Process Explorer the soffice.bin showed considerable memory leak maxing out at ~1.6GB (yes GB), and CPU loads of 55-60% on a Intel Core 2 6300 @ 2.13 GHz.  A lot of thrash of jvm.dll.  Eventually the Expert Config panel did populate. OK'd out of it, and after another 6-7 minutes of the same finally got an actual crash with error "osl thread create failed". Screen clip attached.

Launched. Disabled the Accessibility --> Support Assistive Technology and relaunched. Another attempt at Expert Config--same race condition and memory leak.

Relaunched, disabled Java JRE and relaunched.  Expert Config launches fully populated in seconds ~2-3 seconds.

Disable Java Access Bridge in the JRE (jabswitch -disable). 

Relaunch and set Tools --> Options --> Advanced --> Java Options --Use a Java Runtime environment.

Relaunched. Expert Config launches launches a bit slower, but still fast ~3-4 seconds.

Conclusion--there is something seriously wrong with interface to JRE on Windows when the Java Access Bridge is enabled, it manifests dramatically with the Expert Config routines.

Not sure where to go from here.

Stuart
Comment 5 V Stuart Foote 2013-10-18 22:28:50 UTC
For completeness, running Oracle Java 1.7u40, 32-bit and its built-in Java Access Bridge with JRE_HOME and JAVA_HOME variables set to the JRE install folder and a correct entry in the PATH variable. 

64-bit JRE is not installed on the system.
Comment 6 V Stuart Foote 2013-10-19 18:56:13 UTC
The race condition and memory leak only occurs for the Expert Config panel when Accessibility --> Support assistive technology tools is checked.

Retracting "conclusion" from comment 4

>Conclusion--there is something seriously wrong with interface to JRE on >Windows  when the Java Access Bridge is enabled, it manifests dramatically >with the Expert Config routines.

On another system. With Java JRE 1.7u45 and JAB 2.0.3, but with an older build of master--but full integrated with Windows with WRITE_REGISTRY=1

Version: 4.2.0.0.alpha0+
Build ID: 050248fea53adb6a14b649c5f84dd69a8faff997
TinderBox: Win-x86@39, Branch:master, Time: 2013-10-04_08:16:05

Unchecking the support assistive technology tools, and restarting LODev without change to the JRE and setting fro JAB. The Expert Config panel populates without delay. No fuss.

Check Support assistive technology tools and restart. Selecting the Expert Config panel will enter race condition.

Selecting the Expert Config panel with an active Java JRE, or an active JRE with Java Access Bridge enabled does not cause issues with the Expert Config panel. Issues only when assistve technology tools are active.

So problem seems linked to the UNO Accessibility API events that would be passed via the JAB if assistive technology tools are enabled on Windows.
Comment 7 Efe Gürkan YALAMAN 2013-10-19 19:07:03 UTC
Confirmed on Windows 7 sp1 64-Bit.

I checked the Accessibility page. It might not only on Windows. On Linux instead of loking checkbox we look to system config files. So I assume it is reproduceable on other platforms too. Will check that.

Also page should be on Experimental Features I think. It is not mature right know. Will do it immedieately.
Comment 8 V Stuart Foote 2013-10-19 19:20:02 UTC
Created attachment 87861 [details]
screen capture of locked up LODev 420 session on Fedora 19 GNOME DE with ORCA active

Efe,


It may be worse that just with Windows, just had a go with 

Fedora19 Linux 3.10.11-200.fc19.x86_64 and a GNOME DE

and

Version: 4.2.0.0.alpha0+
Build ID: c2923d47beab284b4bd9af07e1e18eddd59a2530
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2013-10-19_13:32:08

With ORCA running, moving to Tools --> Options --> Expert Config sends LO into race condition using 98% of CPU.

With ORCA disabled, Tools --> Options --> Expert Config takes a few moments of high CPU use and then refreshes listing.

So problem with UNO Accessibility API may be with more than just the Windows builds.

Stuart
Comment 9 Stephan Bergmann 2013-10-21 09:50:30 UTC
(In reply to comment #8)
> It may be worse that just with Windows, just had a go with 
> 
> Fedora19 Linux 3.10.11-200.fc19.x86_64 and a GNOME DE
> 
> and
> 
> Version: 4.2.0.0.alpha0+
> Build ID: c2923d47beab284b4bd9af07e1e18eddd59a2530
> TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time:
> 2013-10-19_13:32:08
> 
> With ORCA running, moving to Tools --> Options --> Expert Config sends LO
> into race condition using 98% of CPU.

But note that this is "just" taking very long, apparently because all elements of the list are reported across the accessibility interface, and svx::OptHeaderTabListBox and its underlying classes make this a ridiculously slow operation (see below for an example backtrace while the operation is in progress).  Eventually, CPU load will go down and the UI will be responsive again.

Local master build on Fedora 19 with "Settings - Universal Access - Screen Reader" enabled:

> #0  0x00007fefb45486e1 in boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<SvTreeListEntry, std::__debug::vector<void*, std::allocator<void*> > >, boost::heap_clone_allocator>::size (this=0x1fb5260) at core/workdir/unxlngx6/UnpackedTarball/boost/boost/ptr_container/detail/reversible_ptr_container.hpp:514
> #1  0x00007fefb4548deb in boost::ptr_sequence_adapter<SvTreeListEntry, std::__debug::vector<void*, std::allocator<void*> >, boost::heap_clone_allocator>::operator[] (this=0x1fb5260, n=10973) at core/workdir/unxlngx6/UnpackedTarball/boost/boost/ptr_container/ptr_sequence_adapter.hpp:325
> #2  0x00007fefb4574f4a in SvTreeList::NextSibling (this=0x1fbb410, pEntry=0x2737a10) at core/svtools/source/contnr/treelist.cxx:818
> #3  0x00007fefb458db04 in SvTreeListBox::NextSibling (this=0x1e3b6b0, pEntry=0x2737a10) at core/svtools/source/contnr/treelistbox.cxx:659
> #4  0x00007fefb458f6a3 in SvTreeListBox::GetLevelChildCount (this=0x1e3b6b0, _pParent=0x0) at core/svtools/source/contnr/treelistbox.cxx:945
> #5  0x00007fefb455277d in SvTabListBox::GetEntryOnPos (this=0x1e3b6b0, _nEntryPos=2378) at core/svtools/source/contnr/svtabbx.cxx:440
> #6  0x00007fefb4552c35 in SvTabListBox::GetCellText (this=0x1e3b6b0, nPos=2378, nCol=3) at core/svtools/source/contnr/svtabbx.cxx:347
> #7  0x00007fefb4556356 in SvHeaderTabListBox::GetAccessibleObjectName (this=0x1e3b6b0, _eType=svt::BBTYPE_TABLECELL, _nPos=9515) at core/svtools/source/contnr/svtabbx.cxx:1037
> #8  0x00007fefb455656f in non-virtual thunk to SvHeaderTabListBox::GetAccessibleObjectName(svt::AccessibleBrowseBoxObjType, int) const () at core/svtools/source/contnr/svtabbx.cxx:1061
> #9  0x00007fef805271b9 in accessibility::AccessibleBrowseBoxCell::AccessibleBrowseBoxCell(const com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessible> &, svt::IAccessibleTableProvider &, const com::sun::star::uno::Reference<com::sun::star::awt::XWindow> &, sal_Int32, sal_uInt16, enum svt::AccessibleBrowseBoxObjType) (this=0x7fef801efd48, _rxParent=uno::Reference to (accessibility::AccessibleBrowseBoxHeaderBar *) 0x7fef8014bd50, _rBrowseBox=..., _xFocusWindow=empty uno::Reference, _nRowPos=2378, _nColPos=3, _eType=svt::BBTYPE_TABLECELL) at core/accessibility/source/extended/accessiblebrowseboxcell.cxx:47
> #10 0x00007fef804fd00b in accessibility::AccessibleBrowseBoxTableCell::AccessibleBrowseBoxTableCell (this=0x7fef801efd48, _rxParent=uno::Reference to (accessibility::AccessibleBrowseBoxHeaderBar *) 0x7fef8014bd50, _rBrowseBox=..., _xFocusWindow=empty uno::Reference, _nRowPos=2378, _nColPos=3, _nOffset=0) at core/accessibility/source/extended/AccessibleBrowseBoxTableCell.cxx:78
> #11 0x00007fef8057dc67 in accessibility::AccessibleFactory::createAccessibleBrowseBoxTableCell (this=0x1f8ad30, _rxParent=uno::Reference to (accessibility::AccessibleBrowseBoxHeaderBar *) 0x7fef8014bd50, _rBrowseBox=..., _xFocusWindow=empty uno::Reference, _nRowId=2378, _nColId=3, _nOffset=0) at core/accessibility/source/helper/acc_factory.cxx:479
> #12 0x00007fef8057dd55 in non-virtual thunk to accessibility::AccessibleFactory::createAccessibleBrowseBoxTableCell(com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessible> const&, svt::IAccessibleTableProvider&, com::sun::star::uno::Reference<com::sun::star::awt::XWindow> const&, int, unsigned short, int) const () at core/accessibility/source/helper/acc_factory.cxx:481
> #13 0x00007fefb4555a25 in SvHeaderTabListBox::CreateAccessibleCell (this=0x1e3b6b0, _nRow=2378, _nColumnPos=3) at core/svtools/source/contnr/svtabbx.cxx:938
> #14 0x00007fefb4555b94 in non-virtual thunk to SvHeaderTabListBox::CreateAccessibleCell(int, unsigned short) () at core/svtools/source/contnr/svtabbx.cxx:947
> #15 0x00007fef804f8c85 in accessibility::AccessibleBrowseBoxTable::getAccessibleChild (this=0x7fef8014bd88, nChildIndex=9515) at core/accessibility/source/extended/AccessibleBrowseBoxTable.cxx:62
> #16 0x00007fef804f8d39 in non-virtual thunk to accessibility::AccessibleBrowseBoxTable::getAccessibleChild(int) () at core/accessibility/source/extended/AccessibleBrowseBoxTable.cxx:64
> #17 0x00007fefa4a77bb8 in AtkListener::updateChildList (this=0x7fef8001cbd0, pContext=0x7fef8014bde8) at core/vcl/unx/gtk/a11y/atklistener.cxx:138
> #18 0x00007fefa4a77a0b in AtkListener::AtkListener (this=0x7fef8001cbd0, pWrapper=0x5cc38e0) at core/vcl/unx/gtk/a11y/atklistener.cxx:49
> #19 0x00007fefa4a92d81 in atk_object_wrapper_new (rxAccessible=uno::Reference to (accessibility::AccessibleTabListBoxTable *) 0x7fef8014be50, parent=0x0) at core/vcl/unx/gtk/a11y/atkwrapper.cxx:822
> #20 0x00007fefa4a92852 in atk_object_wrapper_ref (rxAccessible=uno::Reference to (accessibility::AccessibleTabListBoxTable *) 0x7fef8014be50, create=true) at core/vcl/unx/gtk/a11y/atkwrapper.cxx:763
> #21 0x00007fefa4a94179 in wrapper_ref_child (atk_obj=0x5cc0270, i=1) at core/vcl/unx/gtk/a11y/atkwrapper.cxx:422
> #22 0x00000037c540a46b in add_pending_items () from /lib64/libatk-bridge-2.0.so.0
> #23 0x00000037b6847e06 in g_main_dispatch (context=0x1786720) at gmain.c:3054
> #24 g_main_context_dispatch (context=context@entry=0x1786720) at gmain.c:3630
> #25 0x00000037b6848158 in g_main_context_iterate (context=context@entry=0x1786720, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3701
> #26 0x00000037b68481fc in g_main_context_iteration (context=0x1786720, may_block=1) at gmain.c:3762
> #27 0x00007fefa4a97be0 in GtkData::Yield (this=0xdfc8a0, bWait=true, bHandleAllCurrentEvents=false) at core/vcl/unx/gtk/app/gtkdata.cxx:576
> #28 0x00007fefa4a9ce97 in GtkInstance::Yield (this=0xdfc7f0, bWait=true, bHandleAllCurrentEvents=false) at core/vcl/unx/gtk/app/gtkinst.cxx:425
> #29 0x00007fefb22584d1 in ImplYield (i_bWait=true, i_bAllEvents=false) at core/vcl/source/app/svapp.cxx:364
> #30 0x00007fefb22540e3 in Application::Yield () at core/vcl/source/app/svapp.cxx:396
> #31 0x00007fefb280808c in Dialog::Execute (this=0x1f3f670) at core/vcl/source/window/dialog.cxx:915
> #32 0x00007fef78df2348 in OfaTreeOptionsDialog::Execute (this=0x1f3f670) at core/cui/source/options/treeopt.cxx:2262
> #33 0x00007fef78d175cd in CuiVclAbstractDialog_Impl::Execute (this=0x1f5d460) at core/cui/source/factory/dlgfact.cxx:103
> #34 0x00007fefb52f35aa in SfxApplication::OfaExec_Impl (this=0x182e140, rReq=...) at core/sfx2/source/appl/appserv.cxx:1024
> #35 0x00007fefb52d1078 in SfxStubSfxApplicationOfaExec_Impl (pShell=0x182e140, rReq=...) at core/workdir/unxlngx6/SdiTarget/sfx2/sdi/sfxslots.hxx:1210
> #36 0x00007fefb540c0d2 in SfxShell::CallExec (this=0x182e140, pFunc=0x7fefb52d1050 <SfxStubSfxApplicationOfaExec_Impl(SfxShell*, SfxRequest&)>, rReq=...) at core/include/sfx2/shell.hxx:181
> #37 0x00007fefb584da45 in SfxDispatcher::Call_Impl (this=0x1b5eb60, rShell=..., rSlot=..., rReq=..., bRecord=1 '\001') at core/sfx2/source/control/dispatch.cxx:245
> #38 0x00007fefb58513c1 in SfxDispatcher::_Execute (this=0x1b5eb60, rShell=..., rSlot=..., rReq=..., eCallMode=4) at core/sfx2/source/control/dispatch.cxx:926
> #39 0x00007fefb53dfaa1 in SfxBindings::Execute_Impl (this=0x1b66070, aReq=..., pSlot=0x7fefb5d77428 <aSfxApplicationSlots_Impl+8280>, pShell=0x182e140) at core/sfx2/source/control/bindings.cxx:1290
> #40 0x00007fefb5456415 in SfxDispatchController_Impl::dispatch (this=0x1f25b90, aURL=..., aArgs=empty uno::Sequence, rListener=empty uno::Reference) at core/sfx2/source/control/unoctitm.cxx:726
> #41 0x00007fefb5455365 in SfxOfficeDispatch::dispatch (this=0x7fef79734a30, aURL=..., aArgs=empty uno::Sequence) at core/sfx2/source/control/unoctitm.cxx:359
> #42 0x00007fefb5456b97 in non-virtual thunk to SfxOfficeDispatch::dispatch(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () at core/sfx2/source/control/unoctitm.cxx:361
> #43 0x00007fefa0770f5d in framework::MenuBarManager::Select (this=0x7fef82f91488, pMenu=0x1bdb970) at core/framework/source/uielement/menubarmanager.cxx:1090
> #44 0x00007fefa07707c8 in framework::MenuBarManager::LinkStubSelect (pThis=0x7fef82f91488, pCaller=0x1bdb970) at core/framework/source/uielement/menubarmanager.cxx:1026
> #45 0x00007fefb2239e27 in Link::Call (this=0x1bdb9d8, pCaller=0x1bdb970) at core/include/tools/link.hxx:123
> #46 0x00007fefb28587a3 in Menu::Select (this=0x1bdb970) at core/vcl/source/window/menu.cxx:1157
> #47 0x00007fefb28607be in Menu::ImplCallSelect (this=0x1bdb970) at core/vcl/source/window/menu.cxx:3003
> #48 0x00007fefb28586f8 in Menu::LinkStubImplCallSelect (pThis=0x1bdb970, pCaller=0x0) at core/vcl/source/window/menu.cxx:3000
> #49 0x00007fefb2239e27 in Link::Call (this=0x1f2d600, pCaller=0x0) at core/include/tools/link.hxx:123
> #50 0x00007fefb295a840 in ImplHandleUserEvent (pSVEvent=0x1f27550) at core/vcl/source/window/winproc.cxx:1976
> #51 0x00007fefb2957915 in ImplWindowFrameProc (pWindow=0x183b830, nEvent=22, pEvent=0x1f27550) at core/vcl/source/window/winproc.cxx:2591
> #52 0x00007fefb296d71d in SalFrame::CallCallback (this=0x183bde0, nEvent=22, pEvent=0x1f27550) at core/vcl/inc/salframe.hxx:243
> #53 0x00007fefb296c768 in SalGenericDisplay::DispatchInternalEvent (this=0x17f61c0) at core/vcl/generic/app/gendisp.cxx:91
> #54 0x00007fefa4a98fc8 in GtkData::userEventFn (data=0xdfc8a0) at core/vcl/unx/gtk/app/gtkdata.cxx:935
> #55 0x00007fefa4a990de in call_userEventFn (data=0xdfc8a0) at core/vcl/unx/gtk/app/gtkdata.cxx:945
> #56 0x00000037b6847e06 in g_main_dispatch (context=0x1786720) at gmain.c:3054
> #57 g_main_context_dispatch (context=context@entry=0x1786720) at gmain.c:3630
> #58 0x00000037b6848158 in g_main_context_iterate (context=context@entry=0x1786720, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3701
> #59 0x00000037b68481fc in g_main_context_iteration (context=0x1786720, may_block=1) at gmain.c:3762
> #60 0x00007fefa4a97be0 in GtkData::Yield (this=0xdfc8a0, bWait=true, bHandleAllCurrentEvents=false) at core/vcl/unx/gtk/app/gtkdata.cxx:576
> #61 0x00007fefa4a9ce97 in GtkInstance::Yield (this=0xdfc7f0, bWait=true, bHandleAllCurrentEvents=false) at core/vcl/unx/gtk/app/gtkinst.cxx:425
> #62 0x00007fefb22584d1 in ImplYield (i_bWait=true, i_bAllEvents=false) at core/vcl/source/app/svapp.cxx:364
> #63 0x00007fefb22540e3 in Application::Yield () at core/vcl/source/app/svapp.cxx:396
> #64 0x00007fefb22540b0 in Application::Execute () at core/vcl/source/app/svapp.cxx:345
> #65 0x00007fefb701c359 in desktop::Desktop::Main (this=0x7fffdb9913b8) at core/desktop/source/app/app.cxx:1717
> #66 0x00007fefb2264998 in ImplSVMain () at core/vcl/source/app/svmain.cxx:162
> #67 0x00007fefb2266156 in SVMain () at core/vcl/source/app/svmain.cxx:198
> #68 0x00007fefb7073a91 in soffice_main () at core/desktop/source/app/sofficemain.cxx:85
> #69 0x000000000040096d in sal_main () at core/desktop/source/app/main.c:48
> #70 0x0000000000400947 in main (argc=3, argv=0x7fffdb991568) at core/desktop/source/app/main.c:47
Comment 10 Michael Stahl (CIB) 2013-10-21 12:50:47 UTC
just ran into this problem,
first question i have is why does this:

SvTreeListBox::GetLevelChildCount

... count the elements by iterating when apparently
SvTreeList stores them in a vector which has a size() method...
Comment 11 Michael Stahl (CIB) 2013-10-21 18:17:04 UTC
hopefully Efe can fix the SvTreeList issue...

meanwhile i've fixed a bit of slowness in AccessibleEventNotifier::generateId()
which stupidly iterates over 90k std::map entries...

#0  0x00007f6ac042ced1 in std::_Rb_tree_const_iterator<std::pair<unsigned int const, cppu::OInterfaceContainerHelper*> >::operator== (this=0x7fffd218f730, __x=) at /usr/include/c++/4.8.2/bits/stl_tree.h:299
  File "/lib64/../share/gcc-4.8.2/python/libstdcxx/v6/printers.py", line 389, in to_string
    nodetype = gdb.lookup_type(typename).strip_typedefs()
gdb.error: No type named const std::_Rb_tree_const_iterator<std::pair<unsigned int const, cppu::OInterfaceContainerHelper*> >::_Self &::_Link_type.
#1  0x00007f6ac042d797 in __gnu_debug::_Safe_iterator<std::_Rb_tree_const_iterator<std::pair<unsigned int const, cppu::OInterfaceContainerHelper*> >, std::__debug::map<unsigned int, cppu::OInterfaceContainerHelper*, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, cppu::OInterfaceContainerHelper*> > > >::_M_is_end (this=0x7fffd218f9c0) at /usr/include/c++/4.8.2/debug/safe_iterator.h:464
#2  0x00007f6ac042cf4f in __gnu_debug::_Safe_iterator<std::_Rb_tree_const_iterator<std::pair<unsigned int const, cppu::OInterfaceContainerHelper*> >, std::__debug::map<unsigned int, cppu::OInterfaceContainerHelper*, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, cppu::OInterfaceContainerHelper*> > > >::_M_incrementable (this=0x7fffd218f9c0) at /usr/include/c++/4.8.2/debug/safe_iterator.h:438
#3  0x00007f6ac042bde9 in __gnu_debug::_Safe_iterator<std::_Rb_tree_const_iterator<std::pair<unsigned int const, cppu::OInterfaceContainerHelper*> >, std::__debug::map<unsigned int, cppu::OInterfaceContainerHelper*, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, cppu::OInterfaceContainerHelper*> > > >::operator++ (this=0x7fffd218f9c0) at /usr/include/c++/4.8.2/debug/safe_iterator.h:291master/workdir/unxlngx6/UnpackedTarball/boost/boost/icl/interval_bounds
.hpp
#4  0x00007f6ac042ad17 in comphelper::AccessibleEventNotifier::generateId () at master/comphelper/source/misc/accessibleeventnotifier.cxx:58
#5  0x00007f6ac042aeb3 in comphelper::AccessibleEventNotifier::registerClient () at master/comphelper/source/misc/accessibleeventnotifier.cxx:90
#6  0x00007f6a8b1ada9a in accessibility::AccessibleBrowseBoxBase::addAccessibleEventListener (this=0x7f6a50117bd0, _rxListener=...) at master/accessibility/source/extended/AccessibleBrowseBoxBase.cxx:299
#7  0x00007f6aad9465e3 in DocumentFocusListener::attachRecursive (this=0x7f6a97a3ed38, xAccessible=..., xContext=..., xStateSet=...) at master/vcl/unx/gtk/a11y/atkutil.cxx:320
#8  0x00007f6aad94645a in DocumentFocusListener::attachRecursive (this=0x7f6a97a3ed38, xAccessible=..., xContext=...) at master/vcl/unx/gtk/a11y/atkutil.cxx:296
#9  0x00007f6aad94639d in DocumentFocusListener::attachRecursive (this=0x7f6a97a3ed38, xAccessible=...) at master/vcl/unx/gtk/a11y/atkutil.cxx:282
#10 0x00007f6aad946699 in DocumentFocusListener::attachRecursive (this=0x7f6a97a3ed38, xAccessible=..., xContext=..., xStateSet=...) at master/vcl/unx/gtk/a11y/atkutil.cxx:330
#11 0x00007f6aad94645a in DocumentFocusListener::attachRecursive (this=0x7f6a97a3ed38, xAccessible=..., xContext=...) at master/vcl/unx/gtk/a11y/atkutil.cxx:296
#12 0x00007f6aad94639d in DocumentFocusListener::attachRecursive (this=0x7f6a97a3ed38, xAccessible=...) at master/vcl/unx/gtk/a11y/atkutil.cxx:282
#13 0x00007f6aad946699 in DocumentFocusListener::attachRecursive (this=0x7f6a97a3ed38, xAccessible=..., xContext=..., xStateSet=...) at master/vcl/unx/gtk/a11y/atkutil.cxx:330
#14 0x00007f6aad9473af in handle_get_focus (pEvent=0x7fffd2190350) at master/vcl/unx/gtk/a11y/atkutil.cxx:556
Comment 12 Commit Notification 2013-10-21 18:28:09 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ffd0e2911023e684ca1e206d18b45ef5aa6179f9

fdo#70465: speed up AccessibleEventNotifier::generateId()



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 13 V Stuart Foote 2013-10-24 01:21:54 UTC
On Windows 7 64-bit with Assistive Technology enabled--still have very high memory and CPU use on the Expert Config panel.

Version: 4.2.0.0.alpha0+
Build ID: 5486fd99e185833f1defa9681ef48f50940a65db
TinderBox: Win-X86@42, Branch:master, Time: 2013-10-23_17:16:46

The http://cgit.freedesktop.org/libreoffice/core/commit/?id=ffd0e2911023e684ca1e206d18b45ef5aa6179f9 patch has been applied, so no noticeable improvement with that adjustment.
Comment 14 Efe Gürkan YALAMAN 2013-11-03 15:12:26 UTC
Hi,

I figured out the the reason of the crash on Windows. Everything works as expected on the page. Reason of the crash is out of memory problem.

I was expecting some kind of infinite recursion problem but instead it is the number of the created accessible cells created on the listbox. If I reduce the number of the entries it works as expected.

I start working on optimization.
Comment 15 V Stuart Foote 2013-12-16 21:57:06 UTC
On Windows 7 sp1, 64-bit on an Intel Core2 6400 @ 2.13 GHZ

Version: 4.2.0.0.beta2+
Build ID: d663228bd348c844f38914c9e2167ef01fadf3b3
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-12-14_23:15:05

Get very fast Expert config now with AT disabled. 

But with AT support (NVDA 2013.2) and IAccessible2 based support enabled, launching Expert Config sends CPU usage rocketing running up CPU usage for both LibreOffice and the AT.  With IAccessible2, get a viable expert config table in about 6 minutes -- nicely configured as an IA2 table, with cells containing IA2Accessibletext in a ia2 role of tableCell,  mass accName of cell value and accRole of tableCell.

With AT support (NVDA 2013.2) and Java Accessibility Bridge based support, launching Expert Config runs soffice.bin CPU usage up 47-48% ranges. NVDA also runs into very high usages 38-41%, but the soffice.bin/soffice.exe crash before the expert-config table is generated.

So certainly some Accessibility role related aspect to building table list boxes in a fashion for efficient consumption by AT.
Comment 16 V Stuart Foote 2013-12-16 22:13:51 UTC
Tracking returned to this issue. Adjusting title, setting a11y meta issue trackers.

Releated performance issues of slow list box table build corrected by using fixed field width and height as bug 72125

Continued poor performance in generating the Xaccessible text and table cell values still needs to be resolved.
Comment 17 Michael Meeks 2013-12-17 14:31:00 UTC
Sure sure - there are 35 thousand rows in there, doing a ton of round-trips and creating peers for all of those will take time ...

We need to invest in fixing that I guess; although luckily it's a dark corner of the suite, rather than a truly core feature I think; all those settings are available via editing the XML config file too -> I suspect perhaps disabling the button in a11y mode would be the easiest quick-fix.
Comment 18 Commit Notification 2013-12-31 01:11:28 UTC
Efe Gürkan YALAMAN committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d6f9ddb0aaa3fd9e3877f94a3147c68dd64bc77e

fdo#70465 SvTreeListBox::GetLevelChildCount refactored



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 19 V Stuart Foote 2014-01-03 02:25:15 UTC
Efe, all,
(In reply to comment #18)
> Efe Gürkan YALAMAN committed a patch related to this issue.
> It has been pushed to "master":
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=d6f9ddb0aaa3fd9e3877f94a3147c68dd64bc77e
> 
> fdo#70465 SvTreeListBox::GetLevelChildCount refactored
>

On Windows 7 sp1 64-bit with
Version: 4.3.0.0.alpha0+
Build ID: 96dcea05d2aedceeb27f9506b4178c664be5f80b
TinderBox: Win-x86@39, Branch:master, Time: 2014-01-02_08:18:10

NVDA 2013.2 with IAccessible2 AT activated.

Building the table now down to about 6m 20s, with an soffice.bin process memory use building the accessible table rising to 741MB.  With no AT active, the table is built in <3s, with soffice.bin memory use ~20K.

Improved, but not useable yet.
Comment 20 Jean-Baptiste Faure 2014-02-02 07:47:15 UTC
*** Bug 73721 has been marked as a duplicate of this bug. ***
Comment 21 Jean-Baptiste Faure 2014-02-02 07:49:02 UTC
*** Bug 74350 has been marked as a duplicate of this bug. ***
Comment 22 Efe Gürkan YALAMAN 2014-05-27 07:17:34 UTC
Hi,

Because of GSoC 14 I don't have time for that I am releasing this bug for someone else. Here is Caolan's prototype for working on it.

http://nabble.documentfoundation.org/export-config-a11y-speedup-prototype-td4094771.html
Comment 23 V Stuart Foote 2014-07-03 12:36:39 UTC
adding to MAB for 4.3 -- bug 75025

this aspect, lack of search capability, and unmanageable Window size (bug 73806) really require additional work on the Expert Configuration features early in the 4.3 release cycle.
Comment 24 Björn Michaelsen 2014-08-21 12:17:17 UTC Comment hidden (obsolete)
Comment 25 Jean-Baptiste Faure 2014-09-09 18:00:05 UTC
I am pretty sure that there something else involved in this issue. Indeed with the same build of 4.3.2.0.0+ under Ubuntu 14.04, I do not have the problem
1/ on another PC with Xubuntu 14.04 x86-64 with a Unity session
2/ on the same PC with the guest session and with another new session, both with Unity window-manager with default configuration parameters.

So the problem is in my current Unity session, even without assistive technologies activated.

Best regards. JBF
Comment 26 V Stuart Foote 2014-09-09 20:59:18 UTC
(In reply to comment #25)
> I am pretty sure that there something else involved in this issue.
> ...
> So the problem is in my current Unity session, even without assistive
> technologies activated.

@Jean-Baptiste,

That was a bit confusing, so which Ubuntu OS and DE are you having this issue with?

The slowness IS the churn necessary to convert these thousands of table entries into nice AT aware table elements--but only when an AT is set active (intentionally or not). Still suspect that your DE in a Unity session is setting AT active in some fashion.

Does it improve things for your user account that is having issues if you:
1. rename/delete the existing LibreOffice user profile, or
2. clear/recreate your user account DE configurations?
Comment 27 Jean-Baptiste Faure 2014-09-10 05:32:56 UTC
Hi V Stuart Foote

What do you mean with "DE" ?

1/ renaming or deleting my LibreOffice user profile does not improve things; tried that already.
2/ As I do not want to clear my user account (aka my Ubuntu session profile), I created another one (with default Unity parameters) and it works as expected in this new session.

I suspect that some AT parameters from previous Ubuntu versions and window managers (gnome and xfce) are there and interfere with the current Unity configuration.

Best regards. JBF
Comment 28 V Stuart Foote 2014-09-10 14:25:32 UTC
(In reply to comment #27)
> What do you mean with "DE" ?
Sorry, DE: Desktop Environment
--ref--
http://askubuntu.com/questions/18078/what-is-the-difference-between-a-desktop-environment-and-a-window-manager

And given your description, it still suggests there is some residual configuration of your current Ubuntu profile that is activating an Assistive Technology in your Unity shell. But I have no idea how you would verify that, or better rectify it.

Poking around on the Ubuntu answers site turned up this unanswered question:
https://answers.launchpad.net/ubuntu/+source/unity/+question/199356

but it pointed to issues with GtkTreeView with ATK in this GNOME bug: https://bugzilla.gnome.org/show_bug.cgi?id=577098  

While the bug was closed obsolete with improvements in ATK at-spi handling of GTK and GTKTreeView, it is not clear that the LibreOffice handling of TreeViews, when a11y support is active, has been similarly adjusted. 

Looking at the trace in comment 9--assume that to be the a11y events related to the SvTreeList and SvTreeListBox. Is there a problem in the core svtools? If not, is there a better way to structure the Expert Config tool to reduced the a11y churn?
Comment 29 V Stuart Foote 2014-09-10 15:05:41 UTC
@Jean-Baptiste,

(In reply to comment #28)
>... But I have no idea how you would verify
> that, or better rectify it.

I don't drive a Ubuntu box often, but it looks like the "gnome-session-properties" utility should be available to you from Dash under the Unity shell.  Or, run it from a terminal. 

Then, you'd need to uncheck (and also stop the process) for AT SPI D-Bus Bus ( /usr/lib/at-spi2-core/at-spi-bus-launcher ) and AT SPI Registry (/usr/lib/at-spi/at-spi-registryd ) to disable at-spi and ATK support.

Maybe give that a try and see if Expert Config table then builds quickly for you.
Comment 30 Jean-Baptiste Faure 2014-09-19 19:30:48 UTC
I explored gnome configuration with dconf-editor without success.
Currently, with a Unity session configured from scratch, I do not encounter this problem anymore.

Best regards. JBF
Comment 31 V Stuart Foote 2014-09-19 20:29:49 UTC
@Jean-Baptiste,
(In reply to comment #30)

> Currently, with a Unity session configured from scratch, I do not encounter
> this problem anymore.

Sorry that you had to resort to creating an new scratch Unity user configuration. But it reiterates there is an issue while building a Table listing this large with svtools when an Assistive Technology is active.
Comment 32 Caolán McNamara 2015-06-16 14:32:01 UTC
Mihály has turned this into a hierarchy tree with http://cgit.freedesktop.org/libreoffice/core/commit/?id=db35b73037483cd22cd7d4ac93fe40f23fbe3967 which for me at least has made a massive difference in terms of interactivity and speed to load under GNOME3 with a11y enabled. There's some more work to be done, but in terms of speed this appears solved for me, I'd be interested to hear feed-back for other platforms.
Comment 33 Niklas Johansson 2015-06-17 13:42:26 UTC
Hmm... Testing on Windows I cannot seem to get the screen reader (NVDA) to reach any children. If I expand a leaf in the tree view I see the children but when I press the down arrow the screen reader skips to the next sibling while on screen it skips to the first child.
Same thing on Mac OS X using VoiceOver.
Did this actually work on Linux? In other words did the children get added to/removed from the accessible tree dynamically?