Bug 103852 - win32: clipboard deadlock.
Summary: win32: clipboard deadlock.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Windows (All)
: high critical
Assignee: Not Assigned
URL:
Whiteboard: target:5.4.0 target:5.2.4 target:5.3.0.1
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-11 10:20 UTC by Michael Meeks
Modified: 2017-02-10 07:46 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2016-11-11 10:20:38 UTC
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.
Comment 1 Michael Stahl (CIB) 2016-11-11 11:11:30 UTC
(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.
Comment 2 Michael Stahl (CIB) 2016-11-11 11:14:30 UTC
> it looks like there is no mutex in the clipboard thread?

ah of course not, i forgot it's a COM STA.
Comment 3 Commit Notification 2016-11-24 12:37:36 UTC
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.
Comment 4 Michael Meeks 2016-11-24 13:10:12 UTC
Thanks Tomaz =)
Comment 5 Commit Notification 2016-11-24 13:59:49 UTC
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.
Comment 6 Commit Notification 2016-11-24 14:27:57 UTC
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.
Comment 7 jhertel 2017-02-10 07:46:12 UTC
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.