summaryrefslogtreecommitdiff
path: root/framework
diff options
context:
space:
mode:
authorMike Kaganski <mike.kaganski@collabora.com>2020-05-24 09:18:10 +0200
committerMike Kaganski <mike.kaganski@collabora.com>2020-05-24 10:28:59 +0200
commit1126515226b60630b3a0fd72c45258b230dfe8fd (patch)
treefbc7eedbd9cf2d15db850df27fcfb7217f53d990 /framework
parente3ca594d63daa7e59cee1f9745015f582ab4e773 (diff)
Try to blind-solve cppunittester hangs on Windows
... calling OleInitialize early in sal_main to initialize COM and concurrency. Seeing intermittent hangs in main thread in CAPNDataObject::GetData calling m_rIDataObjectOrg->GetData, and the inner stack waiting objects in the code doing apartment switching (I forgot to save a stack to paste unfortunately), I suspect that being related to incorrect concurrency model. OleInitialize docs [1] mention: Applications that use the following functionality must call OleInitialize before calling any other function in the COM library: * Clipboard * Drag and Drop * Object linking and embedding (OLE) * In-place activation ... Because OLE operations are not thread-safe, OleInitialize specifies the concurrency model as single-thread apartment. CoInitializeEx sets COINIT_MULTITHREADED by default, so possibly that might get called somewhere before clipboard/OLE code is called. I hope that this change would fix those hangs. [1] https://docs.microsoft.com/en-us/windows/win32/api/ole2/nf-ole2-oleinitialize Change-Id: I7213c9d6cb4bd0691a3ce355995157797d7db93f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94675 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Diffstat (limited to 'framework')
0 files changed, 0 insertions, 0 deletions