Bug 116147 - Creating Documents with Wizard Crashes LibreOffice
Summary: Creating Documents with Wizard Crashes LibreOffice
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All Windows (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0 target:6.0.3
Keywords: bibisected, bisected, haveBacktrace, regression
: 116771 116809 116810 116839 (view as bug list)
Depends on:
Blocks: Wizard
  Show dependency treegraph
 
Reported: 2018-03-02 19:25 UTC by Harald Koester
Modified: 2018-04-09 17:49 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
BT (17.26 KB, text/plain)
2018-03-03 12:27 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Koester 2018-03-02 19:25:56 UTC
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.
Comment 1 Julien Nabet 2018-03-02 21:50:27 UTC
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.
Comment 2 MM 2018-03-02 22:08:11 UTC
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.
Comment 3 Julien Nabet 2018-03-02 22:09:52 UTC
Any chance for a backtrace? (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:_How_to_get_a_backtrace)
Comment 4 Telesto 2018-03-03 12:27:26 UTC
Created attachment 140306 [details]
BT
Comment 5 Stephan Bergmann 2018-03-04 16:52:46 UTC
(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".
Comment 6 Xisco Faulí 2018-03-05 15:51:44 UTC
Adding Cc: to Jan-Marek Glogowski
Comment 7 Jan-Marek Glogowski 2018-03-05 19:55:01 UTC
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.
Comment 8 Commit Notification 2018-03-06 08:30:37 UTC
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.
Comment 9 Commit Notification 2018-03-07 14:48:53 UTC
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.
Comment 10 Xisco Faulí 2018-03-08 13:19:03 UTC
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 ?
Comment 11 Xisco Faulí 2018-03-08 17:58:15 UTC
*** Bug 116294 has been marked as a duplicate of this bug. ***
Comment 12 Xisco Faulí 2018-03-09 16:15:27 UTC Comment hidden (obsolete)
Comment 13 Xisco Faulí 2018-04-04 09:48:57 UTC
*** Bug 116771 has been marked as a duplicate of this bug. ***
Comment 14 Xisco Faulí 2018-04-05 12:05:27 UTC
*** Bug 116810 has been marked as a duplicate of this bug. ***
Comment 15 Xisco Faulí 2018-04-05 12:06:07 UTC
*** Bug 116809 has been marked as a duplicate of this bug. ***
Comment 16 Julien Nabet 2018-04-06 21:16:37 UTC
*** Bug 116839 has been marked as a duplicate of this bug. ***
Comment 17 Harald Koester 2018-04-09 17:49:54 UTC
Checked with version 6.0.3. Works as expected now. Hence bug closed.