[Libreoffice-bugs] [Bug 141769] Crash in: cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const &)

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Tue Jun 8 23:46:10 UTC 2021


https://bugs.documentfoundation.org/show_bug.cgi?id=141769

--- Comment #43 from Laurence 'GreenReaper' Parry <greenreaper at hotmail.com> ---
Created attachment 172716
  --> https://bugs.documentfoundation.org/attachment.cgi?id=172716&action=edit
Backtrace from disabling Function Bar on 7.1.3.2 (x86) - non-debug stack

TL;DR:  I end up in the same place with an invalid acquire(). Backtrace
attached up to the exit. Not sure anything after this helps; apologies for the
spam if not.

--

The bibisected build has no symbols, the released build does, so I opened that
in Visual Studio. I was quickly reminded why I don't do that for complex
projects. :-) 

>From the looks of it, it ran into a notifications issue while disposing of the
combo box down spinner button - but this may be a symptom of corruption before
that.

It starts to dispose() ScInputWindow and when VS is set to run with a debug
memory stack an access violation exception occurs via this call chain:
mxTextWindow.disposeAndClear()
m_xBuilder.reset()
VclBuilder::~VclBuilder()
VclBuilder::disposeBuilder()
 aI->m_pWindow.disposeAndClear() within rev. iteration of m_aChildren.rbegin()
Window::dispose()
 xC->dispose();
WeakAggComponentImplHelperBase::dispose()
 rBHelper.aLC.disposeAndClear( aEvt );
OMultiTypeInterfaceContainerHelper::disposeAndClear
 ppListenerContainers[i]->disposeAndClear( rEvt );
OInterfaceContainerHelper::disposeAndClear
 Reference<XEventListener > xLst( aIt.next(), UNO_QUERY );

at this point aIt.aData.pAsVector has supposedly three elements:
* OAccessibleWrapper [0] = {0x0c000850 {m_xParentAccessible={0x0c000704 ... and
a chain above this}}  
* OAccessibleContentWrapper for a VCLAccessibleComponent (window) with
{m_nNotifierClient=0x000003d4 }
* Junk with a broken vptr?

Exception thrown at 0x6E6D6B89 (cppuhelper3MSC.dll) in soffice.bin: 0xC0000005:
Access violation reading location 0x00650066 (trying to call something on the
junk vptr). This exception is caught so as to "be robust".

--

When *not* using a debug stack it proceeds past mxTextWindow.disposeAndClear()
to dispose InterimItemWindow via aWndPos.disposeAndClear - going into
VclReferenceBase::disposeOnce after clReferenceBase::release, resulting in
m_xBuilder.reset() in InterimItemWindow::dispose(). (It never gets to 
m_xVclContentArea.disposeAndClear().)

VclBuilder::disposeBuilder reverse iterates over m_aChildren. At the time of
the crash it seems like there is (in order) a "PosBox" which has not been
disposed, a "pos_window" that has an empty m_pWindow, and an empty element. It
is currently within aI->m_pWindow.disposeAndClear(), at the point of calling
VclReferenceBase::disposeOnce().

This in turn calls ComboBox::dispose() which is at the point of
m_pImpl->m_pBtn.disposeAndClear() (having eliminated its subEdit, ListBox and
floating window). In disassembly it is again calling
VclReferenceBase::disposeOnce().

The combo box button has disposed of any status listener and calls
Control::dispose(). This leads to pWrapper->WindowDestroyed( this ) from
UnoWrapperBase::GetUnoWrapper in vcl::Window::dispose(), and that tries to call
xWindowPeerComp->dispose(). This gets into VCL classes, and by the crash
VCLXButton has finished off all its own disposal and is calling the base class
VCLXGraphicControl::dispose() (VCLXWindow::dispose()). 

It's at this point we get mentions of accessibility:

// #i14103# dispose the accessible context after the window has been destroyed,
// otherwise the old value in the child event fired in
VCLXAccessibleComponent::ProcessWindowEvent()
// for VclEventId::WindowChildDestroyed contains a reference to an already
disposed accessible object
try
{
    css::uno::Reference< css::lang::XComponent > xComponent(
mpImpl->mxAccessibleContext, css::uno::UNO_QUERY );
    if ( xComponent.is() )
>     xComponent->dispose();
}
catch ( const css::uno::Exception& )
{
    OSL_FAIL( "VCLXWindow::dispose: could not dispose the accessible context!"
);
}
[by the crash, mpImpl->mxAccessibleContex is empty, xComponent.is() is true.]

It seems to anticipate some disposal failures, but maybe not the exception
which ends up terminating the application. 

xComponent is a VCLXAccessibleButton. It enters
WeakAggComponentImplHelperBase::dispose and calls rBHelper.aLC.disposeAndClear(
aEvt ), then enters disposing(). This calls
VCLXAccessibleComponent::disposing() - it'd later clear m_sText, which is
empty.

This does DisconnectEvents() and then enters
OAccessibleExtendedComponentHelper::disposing, which gets the SolarMutex guard
and goes into AccessibleEventNotifier::revokeClientNotifyDisposing(
m_pImpl->getClientId( ), *this ); ['this' being the VCLXAccessibleButton].

It's quite complex - comments reference prior re-entrancy problems - but
proceeds to call pListeners->disposeAndClear( aDisposalEvent ). Here it becomes
unstuck:

void OInterfaceContainerHelper2::disposeAndClear( const EventObject & rEvt )
{
    ClearableMutexGuard aGuard( rMutex );
>     OInterfaceIteratorHelper2 aIt( *this );

and this calls
OInterfaceIteratorHelper2::OInterfaceIteratorHelper2(
OInterfaceContainerHelper2 & rCont_ )
    : rCont( rCont_ ),
      bIsList( rCont_.bIsList )
{
...
    else if( aData.pAsInterface )
    {
>        aData.pAsInterface->acquire();

Which appears for some reason to be a pure virtual call.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210608/04c77468/attachment-0001.htm>


More information about the Libreoffice-bugs mailing list