stack:
UAccCOM.dll!ATL::CComObjectRootBase::OuterAddRef() Line 2631
UAccCOM.dll!ATL::CComContainedObject<CAccImage>::AddRef() Line 3719
AccEventCache.dll!00007ffd2039be28()
AccEventCache.dll!00007ffd20355677()
AccEventCache.dll!00007ffd20346d41()
AccEventCache.dll!00007ffd20347f9a()
AccEventCache.dll!00007ffd20338ba2()
AccEventCache.dll!00007ffd20380dd8()
AccEventCache.dll!00007ffd2037fd7b()
AccEventCache.dll!00007ffd2037f7ee()
AccEventCache.dll!00007ffd2037d9e6()
AccEventCache.dll!00007ffd2037d07f()
^ JAWS
GlobalHooksDispatcher.dll!00007ffd214daed4()
GlobalHooksDispatcher.dll!00007ffd214d8d84()
user32.dll!00007ffd492068ac()
ntdll.dll!00007ffd4ae71424()
win32u.dll!NtUserNotifyWinEvent()
winaccessibility.dll!AccObjectWinManager::NotifyAccEvent(com::sun::star::accessibility::XAccessible * pXAcc, UnoMSAAEvent eEvent) Line 182
^ selfAccObj looks very dead here but that is a red herring!
winaccessibility.dll!AccContainerEventListener::FireStateFocusedChange(bool enable) Line 351
winaccessibility.dll!AccContainerEventListener::SetComponentState(__int64 state, bool enable) Line 178
winaccessibility.dll!AccParagraphEventListener::SetComponentState(__int64 state, bool enable) Line 123
winaccessibility.dll!AccContainerEventListener::HandleStateChangedEvent(com::sun::star::uno::Any oldValue, com::sun::star::uno::Any newValue) Line 106
winaccessibility.dll!AccContainerEventListener::notifyEvent(const com::sun::star::accessibility::AccessibleEventObject & aEvent) Line 72
winaccessibility.dll!AccParagraphEventListener::notifyEvent(const com::sun::star::accessibility::AccessibleEventObject & aEvent) Line 77
comphelper.dll!comphelper::AccessibleEventNotifier::addEvent(const unsigned long _nClient, const com::sun::star::accessibility::AccessibleEventObject & _rEvent) Line 256
swlo.dll!SwAccessibleContext::FireAccessibleEvent(com::sun::star::accessibility::AccessibleEventObject & rEvent) Line 457
swlo.dll!SwAccessibleContext::FireStateChangedEvent(__int64 nState, bool bNewState) Line 478
swlo.dll!SwAccessibleParagraph::InvalidateFocus_() Line 397
swlo.dll!SwAccessibleContext::InvalidateFocus() Line 1314
swlo.dll!SwAccessibleMap::InvalidateFocus() Line 2695
swlo.dll!SwViewShell::InvalidateAccessibleFocus() Line 2597
swlo.dll!SwEditWin::GetFocus() Line 5569
vcllo.dll!vcl::Window::CompatGetFocus() Line 3891
vcllo.dll!vcl::Window::ImplGrabFocus(GetFocusFlags nFlags) Line 385
vcllo.dll!vcl::Window::GrabFocus() Line 2983
sfxlo.dll!SfxFrame::GrabFocusOnComponent_Impl() Line 650
The problem is quite simply that CMAccessible::SmartQI() returns a
pointer that is the result of querying the newly created COM aggregation
for IID_IUnknown instead of the requested `iid` interface.
Apparently the wrong result happens to work in many cases, but the
CAccTable actually has 2 interfaces IAccessibleTable and
IAccessibleTable2, and the COM aggravation for IAccessibleTable2 is the
one that crashes; in this case the correct pointer is an offset of 8 to
the start of CAccTable, while in the working cases there is no offset.
So likely the bug was introduced by commits
3b86569fcb and
d0e8e6e3cd but only started to crash with
839dbf9ecf.
Change-Id: I7c7d295c8032b95fe7f64b8da4dd9bc3212563f9
(cherry picked from commit 9502a9f76731afa0f5105e6d79b069222677f88d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194730
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins
Windows Accessibility Bridge
This code provides a bridge between our internal Accessibility
interfaces (implemented on all visible 'things' in the suite: eg.
windows, buttons, entry boxes etc.) - and the Windows MSAA /
IAccessible2 COM interfaces that are familiar to windows users and
Accessible Technologies (ATs) such as the NVDA screen reader.
The code breaks into three bits:
-
source/service/- the UNO service providing the accessibility bridge. It essentially listens to events from the LibreOffice core and creates and synchronises COM peers for our internal accessibility objects when events arrive.
-
source/UAccCom/- COM implementations of the
MSAA/IAccessible2interfaces to provide native peers for the accessibility code.
- COM implementations of the
-
source/UAccCOMIDL/- COM Interface Definition Language (IDL) for UAccCom.
Here is one way of visualising the code / control flow
VCL <-> UNO toolkit <-> UNO a11y <-> win a11y <-> COM / IAccessible2
vcl/ <-> toolkit/ <-> accessibility/ <-> winaccessibility/ <-> UAccCom/
Threading
It's possible that the UNO components are called from threads other
than the main thread, so they have to be synchronized. It would be nice
to put the component into a UNO apartment (and the COM components into STA)
but UNO would spawn a new thread for it so it's not possible.
The COM components also call into the same global AccObjectWinManager
as the UNO components do so both have to be synchronized in the same way.
So we use the SolarMutex for all synchronization since anything else
would be rather difficult to make work. Unfortunately there is a
pre-existing problem in vcl with Win32 Window creation and destruction
on non-main threads where a synchronous SendMessage is used while
the SolarMutex is locked that can cause deadlocks if the main thread is
waiting on the SolarMutex itself at that time and thus not handing the
Win32 message; this is easy to trigger with JunitTests but hopefully
not by actual end users.
Debugging / Playing with winaccessibility
If an assistive technology like NVDA is running when soffice starts, IA2 should be automatically enabled and work as expected.
'accprobe' can be used to introspect the accessibility hierarchy remotely, checkout:
http://accessibility.linuxfoundation.org/a11yweb/util/accprobe/
But often it's more useful to look at NVDA's text output window.
Another tool is Accessibility Insights for Windows: https://accessibilityinsights.io/ It does not support IAccessible2, but the Microsoft Active Accessibility to Microsoft UIA proxy makes some properties, methods and events available to UIA via the LegacyIAccessible pattern: https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementinglegacyiaccessible