<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Crash in: cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const &)" href="https://bugs.documentfoundation.org/show_bug.cgi?id=141769#c43">Comment # 43</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Crash in: cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const &)" href="https://bugs.documentfoundation.org/show_bug.cgi?id=141769">bug 141769</a> from <a class="email" href="mailto:greenreaper@hotmail.com" title="Laurence 'GreenReaper' Parry <greenreaper@hotmail.com>"> Laurence 'GreenReaper' Parry</a> <pre>Created <a href="https://bugs.documentfoundation.org/attachment.cgi?id=172716" name="attach_172716" title="Backtrace from disabling Function Bar on 7.1.3.2 (x86) - non-debug stack">attachment 172716</a> <a href="https://bugs.documentfoundation.org/attachment.cgi?id=172716&action=edit" title="Backtrace from disabling Function Bar on 7.1.3.2 (x86) - non-debug stack">[details]</a> 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>