<https://crashreport.libreoffice.org/stats/signature/TypeDescriptor_Init_Impl::getMutex()> lists lots of various LO 6.* crashes on Windows. One specific example is <https://crashreport.libreoffice.org/stats/crash_details/357f73fc-5cb0-4ec3-84ce-fae571afe3a2>: The crashing thread apparently runs a CMtaOleClipboard::m_hClipboardChangedNotifierThread CMtaOleClipboard::clipboardChangedNotifierThreadProc (dtrans/source/win32/clipb/MtaOleClipb.cxx:676). It calls com::sun::star::datatransfer::DataFormatTranslator::create to create that UNO service from a CDataFormatTranslator ctor (dtrans/source/win32/dtobj/DataFmtTransl.cxx:58), which fails throwing a com::sun::star::uno::DeploymentException. The reason for that failure appears to be that LO is already terminating in thread 0, where it is in cppuhelper::ServiceManager::disposing (cppuhelper/source/servicemanager.cxx:833) already (so no new UNO services can be created any longer). Looking at the code of at least current master (towards LO 6.5): * I assume the thread represented by CMtaOleClipboard::m_hClipboardChangedNotifierThread will get terminated by the > sal_uInt32 dwResult = WaitForSingleObject( > m_hClipboardChangedNotifierThread, MAX_WAIT_SHUTDOWN ); [...] > if ( nullptr != m_hClipboardChangedNotifierThread ) > CloseHandle( m_hClipboardChangedNotifierThread ); code in the ~CMtaOleClipboard dtor (dtrans/source/win32/clipb/MtaOleClipb.cxx). * The CMtaOleClipboard instance is held as CWinClipbImpl::m_MtaOleClipboard member (dtrans/source/win32/clipb/WinClipbImpl.hxx). * The CWinClipbImpl instance in turn is held (via std::unique_ptr) as CWinClipboard::m_pImpl member (dtrans/source/win32/clipb/WinClipboard.hxx). It will be destroyed by the > m_pImpl.reset(); code in CWinClipboard::disposing (dtrans/source/win32/clipb/WinClipboard.cxx). * But CWinClipboard is itself a UNO service (com.sun.star.datatransfer.clipboard.SystemClipboard) whose disposing() is only called during cppuhelper::ServiceManager::disposing.
<https://gerrit.libreoffice.org/c/core/+/86558> "tdf#129930: Dispose SystemClipboard service early enough"
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/974ea67a7c345a8be98c5aaa59baf9b07959b708 tdf#129930: Dispose SystemClipboard service early enough It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Stephan, Should the commit be backported to 6-4 and 6-3 branches ?
(In reply to Commit Notification from comment #2) > Stephan Bergmann committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 974ea67a7c345a8be98c5aaa59baf9b07959b708 > > tdf#129930: Dispose SystemClipboard service early enough > > It will be available in 6.5.0. I /assume/ that this fixes <https://crashreport.libreoffice.org/stats/signature/TypeDescriptor_Init_Impl::getMutex()>. I'm a bit reluctant to backport the fix without it first proving itself on master, though, as messing with the order in which things are disposed can have unexpected consequences.