When running on Windows for long periods - after say 40+ runs of a test we have at Collabora - we get a deadlock like this: ChildEBP RetAddr 0175f1a4 7570112f ntdll!NtWaitForMultipleObjects+0xc 0175f330 7557d433 KERNELBASE!WaitForMultipleObjectsEx+0xcc 0175f394 7557d17f USER32!MsgWaitForMultipleObjectsEx+0x163 0175f3b0 6430949e USER32!MsgWaitForMultipleObjects+0x1f 0175f41c 64303bf2 sysdtrans!CMtaOleClipboard::getClipboard+0xbe [c:\lo\libo-core\dtrans\source\win32\clipb\mtaoleclipb.cxx @ 379] 0175f45c 6430728a sysdtrans!CWinClipbImpl::getContents+0xd2 [c:\lo\libo-core\dtrans\source\win32\clipb\winclipbimpl.cxx @ 101] 0175f498 6e84b784 sysdtrans!CWinClipboard::getContents+0xba [c:\lo\libo-core\dtrans\source\win32\clipb\winclipboard.cxx @ 80] 0175f4f8 64b392d6 mergedlo!TransferableDataHelper::CreateFromSystemClipboard+0x94 [c:\lo\libo-core\svtools\source\misc\transfer.cxx @ 2114] 0175f564 64b3919e swlo!SwBaseShell::StateClpbrd+0x116 [c:\lo\libo-core\sw\source\uibase\shells\basesh.cxx @ 462] 0175f570 6e388ca4 swlo!SfxStubSwBaseShellStateClpbrd+0xe [c:\lo\libo-core\workdir\sditarget\sw\sdi\swslots.hxx @ 2073] 0175f584 6e37db93 mergedlo!SfxDispatcher::FillState_+0x44 [c:\lo\libo-core\sfx2\source\control\dispatch.cxx @ 1908] 0175f5d4 6e37c26f mergedlo!SfxBindings::Update_Impl+0x103 [c:\lo\libo-core\sfx2\source\control\bindings.cxx @ 326] 0175f604 6e37c0ae mergedlo!SfxBindings::NextJob_Impl+0x1af [c:\lo\libo-core\sfx2\source\control\bindings.cxx @ 1502] 0175f610 6f4866ad mergedlo!SfxBindings::LinkStubNextJob+0xe [c:\lo\libo-core\sfx2\source\control\bindings.cxx @ 1435] 0175f61c 6f46b822 mergedlo!Timer::Invoke+0xd [c:\lo\libo-core\vcl\source\app\timer.cxx @ 88] 0175f630 6f46b597 mergedlo!Scheduler::ProcessTaskScheduling+0x62 [c:\lo\libo-core\vcl\source\app\scheduler.cxx @ 177] 0175f638 6f540eb2 mergedlo!Scheduler::CallbackTaskScheduling+0x7 [c:\lo\libo-core\vcl\source\app\scheduler.cxx @ 165] 0175f648 6f53f466 mergedlo!EmitTimerCallback+0x32 [c:\lo\libo-core\vcl\win\app\saltimer.cxx @ 173] 0175f674 6f53f570 mergedlo!SalComWndProc+0x196 [c:\lo\libo-core\vcl\win\app\salinst.cxx @ 733] 0175f6c0 75578e71 mergedlo!SalComWndProcW+0x60 [c:\lo\libo-core\vcl\win\app\salinst.cxx @ 766] 0175f6ec 755790d1 USER32!_InternalCallWinProc+0x2b 0175f780 7557a66f USER32!UserCallWinProcCheckWow+0x18e 0175f7ec 7557a6e0 USER32!DispatchMessageWorker+0x208 0175f7f8 6f53efd4 USER32!DispatchMessageW+0x10 0175f82c 6f53ee2a mergedlo!ImplSalYield+0x64 [c:\lo\libo-core\vcl\win\app\salinst.cxx @ 589] 0175f854 6f480d16 mergedlo!WinSalInstance::DoYield+0xca [c:\lo\libo-core\vcl\win\app\salinst.cxx @ 654] 0175f878 6f47e015 mergedlo!Application::Yield+0x56 [c:\lo\libo-core\vcl\source\app\svapp.cxx @ 556] 0175f8a8 6e5be1b9 mergedlo!Application::Execute+0x145 [c:\lo\libo-core\vcl\source\app\svapp.cxx @ 473] 0175fa1c 6f4856b3 mergedlo!desktop::Desktop::Main+0xcd9 [c:\lo\libo-core\desktop\source\app\app.cxx @ 16707566] 0175fa44 6f485a79 mergedlo!ImplSVMain+0x63 [c:\lo\libo-core\vcl\source\app\svmain.cxx @ 185] 0175fa50 6e5d86d9 mergedlo!SVMain+0x29 [c:\lo\libo-core\vcl\source\app\svmain.cxx @ 224] 0175fac0 00d2101e mergedlo!soffice_main+0x79 [c:\lo\libo-core\desktop\source\app\sofficemain.cxx @ 165] vs. 8 Id: 8e0.ed8 Suspend: 1 Teb: 7edde000 Unfrozen ChildEBP RetAddr 11d7f90c 7779e4b7 ntdll!NtWaitForSingleObject+0xc 11d7f980 7779e33b ntdll!RtlpWaitOnCriticalSection+0xd0 11d7f9ac 7779e365 ntdll!RtlpEnterCriticalSectionContended+0xa0 11d7f9b4 6d7ba55c ntdll!RtlEnterCriticalSection+0x42 11d7f9c0 6f53fe6c sal3!osl_acquireMutex+0xc [c:\lo\libo-core\sal\osl\w32\mutex.c @ 72] 11d7f9cc 64aa82d9 mergedlo!SalYieldMutex::acquire+0xc [c:\lo\libo-core\vcl\win\app\salinst.cxx @ 140] 11d7f9f8 64aa8b52 swlo!SwTransferable::~SwTransferable+0x69 [c:\lo\libo-core\sw\source\uibase\dochdl\swdtflvr.cxx @ 244] 11d7fa08 6d696077 swlo!SwTransferable::`vector deleting destructor'+0x42 11d7fa18 64310713 cppuhelper3MSC!cppu::OWeakObject::release+0x27 [c:\lo\libo-core\cppuhelper\source\weak.cxx @ 231] 11d7fa48 643107bb sysdtrans!CXTDataObject::~CXTDataObject+0x103 [c:\lo\libo-core\dtrans\source\win32\dtobj\xtdataobject.hxx @ 67] 11d7fa54 64310ecf sysdtrans!CXTDataObject::`scalar deleting destructor'+0xb 11d7fa64 6430f92e sysdtrans!CXTDataObject::Release+0x1f [c:\lo\libo-core\dtrans\source\win32\dtobj\xtdataobject.cxx @ 114] 11d7fa88 6430fb4f sysdtrans!CXNotifyingDataObject::`scalar deleting destructor'+0x6e 11d7fa9c 753e5a06 sysdtrans!CXNotifyingDataObject::Release+0x2f [c:\lo\libo-core\dtrans\source\win32\dtobj\xnotifyingdataobject.cxx @ 87] 11d7fac8 753e5a3e ole32!RemoveClipboardDataObject+0xdc3 [d:\9147\com\ole32\ole232\clipbrd\clipapi.cpp @ 3648] 11d7fadc 75578e71 ole32!ClipboardWndProc+0x11be [d:\9147\com\ole32\ole232\clipbrd\clipapi.cpp @ 623] 11d7fb08 755790d1 USER32!_InternalCallWinProc+0x2b 11d7fb9c 7557932c USER32!UserCallWinProcCheckWow+0x18e 11d7fbfc 755a4560 USER32!DispatchClientMessage+0xdc 11d7fc40 777c0ca6 USER32!__fnINDESTROYCLIPBRD+0x40 11d7fc54 01e7ed90 ntdll!KiUserCallbackDispatcher+0x36 WARNING: Frame IP not in any known module. Following frames may be wrong. 11d7fc9c 64309d62 0x1e7ed90 11d7fcd8 64309739 sysdtrans!CMtaOleClipboard::run+0x62 [c:\lo\libo-core\dtrans\source\win32\clipb\mtaoleclipb.cxx @ 726] 11d7fce0 7199c01d sysdtrans!CMtaOleClipboard::oleThreadProc+0x19 [c:\lo\libo-core\dtrans\source\win32\clipb\mtaoleclipb.cxx @ 747] 11d7fd18 7199c001 MSVCR120!_callthreadstartex+0x1b [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 376] It seems to me that one 'obvious' fix here is to post the destruction of the XTransferrable from class CXTDataObject : public IDataObject { public: ... css::uno::Reference< css::datatransfer::XTransferable > m_XTransferable; To the main thread with an Application::PostUserEvent - which is commonly supposed to be thread-safe ;-) Alternatively - presumably dropping the SolarMutex as we go down this path: mergedlo!TransferableDataHelper::CreateFromSystemClipboard+0x94 [c:\lo\libo-core\svtools\source\misc\transfer.cxx @ 2114] might work - at the cost of some significant re-enterancy hazard. Thoughts appreciated.
(In reply to Michael Meeks from comment #0) > It seems to me that one 'obvious' fix here is to post the destruction of the > XTransferrable from > > class CXTDataObject : public IDataObject > { > public: > ... > css::uno::Reference< css::datatransfer::XTransferable > > m_XTransferable; > > To the main thread with an Application::PostUserEvent - which is commonly > supposed to be thread-safe ;-) yes that sounds reasonable, the good solutions are to delay the destruction until the mutex in the clipboard thread is released, or move destruction to a different thread. it looks like there is no mutex in the clipboard thread? just a event loop... that would make it more difficult... better to try your obvious solution. > Alternatively - presumably dropping the SolarMutex as we go down this path: > > mergedlo!TransferableDataHelper::CreateFromSystemClipboard+0x94 > [c:\lo\libo-core\svtools\source\misc\transfer.cxx @ 2114] > > might work - at the cost of some significant re-enterancy hazard. eeek. i don't like all those SolarMutexReleasers we currently have.
> it looks like there is no mutex in the clipboard thread? ah of course not, i forgot it's a COM STA.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bdd108cd72e630189c360c5327c480c1d64d55b1 tdf#103852 avoid clipboard deadlock It will be available in 5.4.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.
Thanks Tomaz =)
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=69016f3052dcefa76486d83adbcc6d83df7d674b&h=libreoffice-5-2 tdf#103852 avoid clipboard deadlock It will be available in 5.2.4. 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.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c53cf1dfc5eacd8fee6b2b549ec6b59ad927e01c&h=libreoffice-5-3 tdf#103852 avoid clipboard deadlock It will be available in 5.3.0.1. 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.
Feedback: I am currently using version 5.2.5.1 on Windows 10 and the lock I reported in Bug 98002 (deadlock with the Clipboard Help+Spell program) just happened again: The user interfaces of both LibreOffice and Clipboard Help+Spell suddenly locked while I was typing, and when I killed the Clipboard Help+Spell process, LibreOffice immediately became responsive again. Whether that is the same problem as this present bug I don't know, but they seem related enough for me to find it relevant to mention it here. I am not using 5.3.0.1 due to another bug (Bug 105844 – FILESAVE: Very slow saving compared to 5.2.5), so I can't tell if the problem exists in version 5.3.0.1 too. But according to Comment 5, the current attempted fix should also have been integrated in version 5.2.5. After trying for several hours, I was not able to set up a functioning compile and debug environment in Windows due to old and lacking documentation. So I can't do any debugging unless someone gives me precise instructions on how to do that, i.e. tells me exactly what to do when the deadlock happens again. Again, the two bugs might be unrelated, but they do both seem to have something to do with a deadlock and the clipboard.