[Libreoffice-bugs] [Bug 116147] Creating Documents with Wizard Crashes LibreOffice

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #7 from Jan-Marek Glogowski <glogow at fbihome.de> ---
In my own backtrace we abort() because we try to release the SolarMutex, which
is not locked.

The last releaser before the abort() in the backtrace is in
VCLXWindowImpl::OnProcessCallbacks line 290
The big question: who is responsible to take the lock, so we can actually
release it in fpicker::win32::vista::Request::wait?

... abort() ...
fps.dll!SolarMutexReleaser::SolarMutexReleaser() Zeile 1484     C++
^^^^ Tries to release the SolarMutex

fps.dll!fpicker::win32::vista::Request::wait(long nMilliSeconds) Zeile 44      
C++
fps.dll!fpicker::win32::vista::AsyncRequests::triggerRequestBlocked(const
std::shared_ptr<fpicker::win32::vista::Request> & rRequest) Zeile 111 C++
fps.dll!fpicker::win32::vista::AsyncRequests::triggerRequestThreadAware(const
std::shared_ptr<fpicker::win32::vista::Request> & rRequest, short nWait) Zeile
144        C++
fps.dll!fpicker::win32::vista::VistaFilePicker::getSelectedFiles() Zeile 221   
C++
fps.dll!fpicker::win32::vista::VistaFilePicker::getFiles() Zeile 205    C++
msci_uno.dll!`anonymous namespace'::callVirtualMethod(void * pAdjustedThisPtr,
long nVtableIndex, void * pRegisterReturn, _typelib_TypeClass eReturnTypeClass,
long * pStackLongs, long nStackLongs) Zeile 74   C++
msci_uno.dll!`anonymous
namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis,
bridges::cpp_uno::shared::VtableSlot aVtableSlot,
_typelib_TypeDescriptionReference * pReturnTypeRef, long nParams,
_typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs,
_uno_Any * * ppUnoExc) Zeile 249        C++
msci_uno.dll!unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const
_typelib_TypeDescription * pMemberDescr, void * pReturn, void * * pArgs,
_uno_Any * * ppException) Zeile 430       C++
reflectionlo.dll!stoc_corefl::IdlInterfaceMethodImpl::invoke(const
com::sun::star::uno::Any & rObj,
com::sun::star::uno::Sequence<com::sun::star::uno::Any> & rArgs) Zeile 686  C++
invocationlo.dll!stoc_inv::Invocation_Impl::invoke(const rtl::OUString &
FunctionName, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> &
InParams, com::sun::star::uno::Sequence<short> & OutIndices,
com::sun::star::uno::Sequence<com::sun::star::uno::Any> & OutParams) Zeile 654 
    C++ 
pyuno_d.pyd!pyuno::PyUNO_callable_call(_object * self, _object * args, _object
* __formal) Zeile 96     C++
python35_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Zeile
2166    C
...
<many more python35 calls>
...     
python35_d.dll!PyObject_CallObject(_object * o, _object * a) Zeile 2092 C
pyuno_d.pyd!pyuno::Adapter::invoke(const rtl::OUString & aFunctionName, const
com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aParams,
com::sun::star::uno::Sequence<short> & aOutParamIndex,
com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aOutParam) Zeile 250 
C++
msci_uno.dll!`anonymous namespace'::callVirtualMethod(void * pAdjustedThisPtr,
long nVtableIndex, void * pRegisterReturn, _typelib_TypeClass eReturnTypeClass,
long * pStackLongs, long nStackLongs) Zeile 74   C++
msci_uno.dll!`anonymous
namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis,
bridges::cpp_uno::shared::VtableSlot aVtableSlot,
_typelib_TypeDescriptionReference * pReturnTypeRef, long nParams,
_typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs,
_uno_Any * * ppUnoExc) Zeile 249        C++     
msci_uno.dll!unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const
_typelib_TypeDescription * pMemberDescr, void * pReturn, void * * pArgs,
_uno_Any * * ppException) Zeile 430       C++     
invocadaptlo.dll!stoc_invadp::AdapterImpl::invoke(const
_typelib_TypeDescription * pMemberType, void * pReturn, void * * pArgs,
_uno_Any * * ppException) Zeile 466     C++     
invocadaptlo.dll!adapter_dispatch(_uno_Interface * pUnoI, const
_typelib_TypeDescription * pMemberType, void * pReturn, void * * pArgs,
_uno_Any * * ppException) Zeile 616     C++     
msci_uno.dll!`anonymous
namespace'::cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy * pThis,
const _typelib_TypeDescription * pMemberTypeDescr,
_typelib_TypeDescriptionReference * pReturnTypeRef, long nParams,
_typelib_MethodParameter * pParams, void * * pCallStack, __int64 *
pRegisterReturn) Zeile 155        C++     
msci_uno.dll!`anonymous namespace'::cpp_mediate(void * * pCallStack, long
nFunctionIndex, long nVtableOffset, __int64 * pRegisterReturn) Zeile 336     
C++     
msci_uno.dll!`anonymous namespace'::cpp_vtable_call() Zeile 371 C++ 
tklo.dll!ActionListenerMultiplexer::actionPerformed(const
com::sun::star::awt::ActionEvent & evt) Zeile 145     C++     
tklo.dll!ActionListenerMultiplexer::actionPerformed(const
com::sun::star::awt::ActionEvent & evt) Zeile 145     C++     
tklo.dll!VCLXButton::ProcessWindowEvent::__l8::<lambda>() Zeile 591     C++
^^^ This expects the SolarMutex to be locked, as it would call
ImplExecuteAsyncWithoutSolarLock as the next function, which calls
callBackAsync, which starts with DBG_TESTSOLARMUTEX();

tklo.dll!std::_Invoker_functor::_Call<void <lambda>(void)
&>(VCLXButton::ProcessWindowEvent::__l8::void <lambda>(void) & _Obj) Zeile 1377
      C++     
tklo.dll!std::invoke<void <lambda>(void)
&>(VCLXButton::ProcessWindowEvent::__l8::void <lambda>(void) & _Obj) Zeile 1443
       C++     
tklo.dll!std::_Invoke_ret<void,void <lambda>(void) &>(std::_Forced<void,1>
__formal, VCLXButton::ProcessWindowEvent::__l8::void <lambda>(void) &
<_Vals_0>) Zeile 1461  C++
tklo.dll!std::_Func_impl<void
<lambda>(void),std::allocator<int>,void>::_Do_call() Zeile 212    C++
tklo.dll!std::_Func_class<void>::operator()() Zeile 280 C++ 
tklo.dll!VCLXWindowImpl::OnProcessCallbacks(void * __formal) Zeile 296  C++
^^^ releases the SolarMutex in line 290 before invoking the callbacks

But VCLXWindowImpl::OnProcessCallbacks is broken in itself. First it uses a
SolarMutexGuard to copy the callback list and later a SolarMutexReleaser, when
the SolarMutexGuard was already released.
The only way this can work: the function is already called with the SolarMutex,
otherwise the SolarMutexReleaser would already fail there.

So I had put a SolarMutexGuard into VCLXButton::ProcessWindowEvent, but that
didn't help - same backtrace.

Then I looked into AsyncRequests::triggerRequestThreadAware - and this code is
crazy too.

There is Request::waitProcessMessages, which takes a SolarMutexGuard and there
is Request::wait, which takes a SolarMutexReleaser - how nice.

The Gtk+ backend just takes a SolarMutexGuard in (almost) every file picker
call, so we'll do the same for the Windows file picker.

-- 
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/20180305/0e6159fc/attachment.html>