In order to reproduce: [1] Start LibreOffice and open letter wizard: File > Wizards > Letter… [2] Click several times 'Next'. You do not need to change anything. Then 'Finish'. A 'Save as' dialogue is displayed. [3] Save document as template. A message is displayed, that LibreOffice is no longer working. You can only close LibreOffice. Expected: Saving of document and no crash. [4] Close program. LibreOffice is completely closed. There is the danger of data loss if a document has been edited and has not been saved before using the wizard. OS: Win10, 64 bit. Bug exists in versions 6.0.0, 6.0.1 and 6.0.2, but not in 5.4.4 (all 64 bit). Bug 114881 describes the same problem, but according that report the bug has been fixed.
Just for the record, on pc Debian x86-64 with master sources updated today or with LO Debian package 6.0.1, I don't reproduce this.
Confirmed on windows 7 x64 with Version: 6.0.2.1 (x64) Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89 CPU threads: 3; OS: Windows 6.1; UI render: default Something like it supposed to be fixed (bug 114881), as file > wizard > agenda / fax also crashes. But clearly it isn't fixed.
Any chance for a backtrace? (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:_How_to_get_a_backtrace)
Created attachment 140306 [details] BT
(In reply to MM from comment #2) > Something like it supposed to be fixed (bug 114881), as file > wizard > > agenda / fax also crashes. But clearly it isn't fixed. As per backtrace in attachment 140306 [details], this is rather unrelated to the issue fixed in bug 114881, and instead triggers one of the two calls to std::abort() in GenericSolarMutex::doRelease (comphelper/source/misc/solarmutex.cxx) introduced with <https://cgit.freedesktop.org/libreoffice/core/commit/?id=3840aede596e6fc24f7ed7df9100fb028134aac6> "Unify SolarMutex implementations".
Adding Cc: to Jan-Marek Glogowski
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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3e38b81a65ced47595e9760bdc622d9434b72cc0 tdf#116147 guard triggerRequestThreadAware It will be available in 6.1.0. 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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0898760c20c44e18278c5cb7513d11d041820d42&h=libreoffice-6-0 tdf#116147 guard triggerRequestThreadAware It will be available in 6.0.3. 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.
Fixed in Version: 6.1.0.0.alpha0+ Build ID: d6b33e49a5e9c51827eda9c5ba16d8daeb27e8af CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-03-07_23:26:53 Locale: es-ES (es_ES); Calc: group @Jan-Marek Glogowski, is it ok if we close this as RESOLVED FIXED ?
*** Bug 116294 has been marked as a duplicate of this bug. ***
*** Bug 116771 has been marked as a duplicate of this bug. ***
*** Bug 116810 has been marked as a duplicate of this bug. ***
*** Bug 116809 has been marked as a duplicate of this bug. ***
*** Bug 116839 has been marked as a duplicate of this bug. ***
Checked with version 6.0.3. Works as expected now. Hence bug closed.