vcl/win/dtrans/WinClipboard.cxx | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
New commits: commit 637583b9f94fe6f7005bda7f3a8c489bec7b3a61 Author: Mike Kaganski <[email protected]> AuthorDate: Sun Nov 3 22:49:28 2024 +0500 Commit: Xisco Fauli <[email protected]> CommitDate: Wed Nov 6 21:02:03 2024 +0100 Related: tdf#163730 Avoid potential deadlock Similar to commit 43e5118496ae0c9b8f81a54574874eda7d439dbb (Related: tdf#163730 Avoid deadlock, 2024-11-03). I haven't seen this scenario myself, but seems likely to be possible. Change-Id: Ie6bb69e7ebe12a69e4dabee9103de32611235807 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175971 Tested-by: Jenkins Reviewed-by: Mike Kaganski <[email protected]> (cherry picked from commit 3015db08c9a8a1b29af1018044955c905c9015aa) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175920 Reviewed-by: Xisco Fauli <[email protected]> diff --git a/vcl/win/dtrans/WinClipboard.cxx b/vcl/win/dtrans/WinClipboard.cxx index 5760155beaa1..3603cf55f5d9 100644 --- a/vcl/win/dtrans/WinClipboard.cxx +++ b/vcl/win/dtrans/WinClipboard.cxx @@ -172,6 +172,9 @@ void SAL_CALL CWinClipboard::setContents( const uno::Reference<datatransfer::XTransferable>& xTransferable, const uno::Reference<datatransfer::clipboard::XClipboardOwner>& xClipboardOwner) { + // The object must be destroyed only outside of the mutex lock, because it may call + // CWinClipboard::onReleaseDataObject in another thread of this process synchronously + css::uno::Reference<css::datatransfer::XTransferable> prev_foreignContent; std::unique_lock aGuard(m_aMutex); if (m_bDisposed) @@ -180,7 +183,8 @@ void SAL_CALL CWinClipboard::setContents( IDataObjectPtr pIDataObj; - m_foreignContent.clear(); + prev_foreignContent = std::move(m_foreignContent); // clear m_foreignContent + assert(!m_foreignContent.is()); m_pCurrentOwnClipContent = nullptr; if (xTransferable.is()) @@ -284,7 +288,7 @@ void SAL_CALL CWinClipboard::removeClipboardListener( void CWinClipboard::handleClipboardContentChanged() { // The object must be destroyed only outside of the mutex lock, because it may call - // CWinClipboard::onReleaseDataObject in another thread of this process + // CWinClipboard::onReleaseDataObject in another thread of this process synchronously css::uno::Reference<css::datatransfer::XTransferable> old_foreignContent; { std::unique_lock aGuard(m_aMutex);
