<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - CMtaOleClipboard::m_hClipboardChangedNotifierThread still running during cppuhelper::ServiceManager::disposing"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=129930">129930</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>CMtaOleClipboard::m_hClipboardChangedNotifierThread still running during cppuhelper::ServiceManager::disposing
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>sbergman@redhat.com
</td>
</tr></table>
<p>
<div>
<pre><<a href="https://crashreport.libreoffice.org/stats/signature/TypeDescriptor_Init_Impl::getMutex">https://crashreport.libreoffice.org/stats/signature/TypeDescriptor_Init_Impl::getMutex</a>()>
lists lots of various LO 6.* crashes on Windows. One specific example is
<<a href="https://crashreport.libreoffice.org/stats/crash_details/357f73fc-5cb0-4ec3-84ce-fae571afe3a2">https://crashreport.libreoffice.org/stats/crash_details/357f73fc-5cb0-4ec3-84ce-fae571afe3a2</a>>:
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
<span class="quote">> sal_uInt32 dwResult = WaitForSingleObject(
> m_hClipboardChangedNotifierThread, MAX_WAIT_SHUTDOWN );</span >
[...]
<span class="quote">> if ( nullptr != m_hClipboardChangedNotifierThread )
> CloseHandle( m_hClipboardChangedNotifierThread );</span >
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
<span class="quote">> m_pImpl.reset();</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>