summaryrefslogtreecommitdiff
path: root/embeddedobj/source/inc
AgeCommit message (Collapse)Author
2024-10-18Avoid deadlockMike Kaganski
As seen in the following call stacks: Main thread sal3!osl_acquireMutex+0x49 [libre-office-git-repo\sal\osl\w32\mutex.cxx @ 65] emboleobj!osl::Mutex::acquire+0x9 [libre-office-git-repo\include\osl\mutex.hxx @ 63] emboleobj!osl::ClearableGuard<osl::Mutex>::{ctor}+0xd [libre-office-git-repo\include\osl\mutex.hxx @ 182] emboleobj!osl::ResettableGuard<osl::Mutex>::{ctor}+0xd [libre-office-git-repo\include\osl\mutex.hxx @ 236] emboleobj!OleEmbeddedObject::getStatus+0x72 [libre-office-git-repo\embeddedobj\source\msole\oleembed.cxx @ 1133] sfxlo!SfxViewShell::CheckIPClient_Impl+0x42 [libre-office-git-repo\sfx2\source\view\viewsh.cxx @ 3563] sfxlo!SfxInPlaceClient_Impl::TimerHdl+0x40 [libre-office-git-repo\sfx2\source\view\ipclient.cxx @ 628] sfxlo!SfxInPlaceClient_Impl::LinkStubTimerHdl+0x53 [libre-office-git-repo\sfx2\source\view\ipclient.cxx @ 624] vcllo!Scheduler::CallbackTaskScheduling+0x130e [libre-office-git-repo\vcl\source\app\scheduler.cxx @ 511] vclplug_winlo!WinSalTimer::ImplHandleElapsedTimer+0x2e [libre-office-git-repo\vcl\win\app\saltimer.cxx @ 167] vclplug_winlo!ImplSalYield+0x14f [libre-office-git-repo\vcl\win\app\salinst.cxx @ 525] vclplug_winlo!WinSalInstance::DoYield+0xad [libre-office-git-repo\vcl\win\app\salinst.cxx @ 581] vcllo!ImplYield+0x367 [libre-office-git-repo\vcl\source\app\svapp.cxx @ 393] vcllo!Application::Execute+0xfa [libre-office-git-repo\vcl\source\app\svapp.cxx @ 369] sofficeapp!desktop::Desktop::Main+0x173f [libre-office-git-repo\desktop\source\app\app.cxx @ 1605] vcllo!ImplSVMain+0xda [libre-office-git-repo\vcl\source\app\svmain.cxx @ 229] sofficeapp!soffice_main+0xf3 [libre-office-git-repo\desktop\source\app\sofficemain.cxx @ 94] Request thread sal3!osl_acquireMutex+0x49 [libre-office-git-repo\sal\osl\w32\mutex.cxx @ 65] vclplug_winlo!osl::Mutex::acquire+0xa [libre-office-git-repo\include\osl\mutex.hxx @ 63] vclplug_winlo!SalYieldMutex::doAcquire+0x91 [libre-office-git-repo\vcl\win\app\salinst.cxx @ 148] emboleobj!SolarMutexReleaser::{dtor}+0xc [libre-office-git-repo\include\vcl\svapp.hxx @ 1425] emboleobj!OleComponent::StoreOwnTmpIfNecessary+0x1d3 [libre-office-git-repo\embeddedobj\source\msole\olecomponent.cxx @ 1365] emboleobj!OleEmbeddedObject::StoreObjectToStream+0x2f [libre-office-git-repo\embeddedobj\source\msole\olepersist.cxx @ 1032] emboleobj!OleEmbeddedObject::StoreToLocation_Impl+0x3cc [libre-office-git-repo\embeddedobj\source\msole\olepersist.cxx @ 1169] emboleobj!OleEmbeddedObject::storeAsEntry+0x152 [libre-office-git-repo\embeddedobj\source\msole\olepersist.cxx @ 1523] comphelper!comphelper::EmbeddedObjectContainer::StoreEmbeddedObject+0x490 [libre-office-git-repo\comphelper\source\container\embeddedobjectcontainer.cxx @ 501] comphelper!comphelper::EmbeddedObjectContainer::InsertEmbeddedObject+0x6f [libre-office-git-repo\comphelper\source\container\embeddedobjectcontainer.cxx @ 518] comphelper!comphelper::EmbeddedObjectContainer::RemoveEmbeddedObject+0x388 [libre-office-git-repo\comphelper\source\container\embeddedobjectcontainer.cxx @ 945] comphelper!comphelper::EmbeddedObjectContainer::RemoveEmbeddedObject+0x46 [libre-office-git-repo\comphelper\source\container\embeddedobjectcontainer.cxx @ 831] swlo!SwOLENode::SavePersistentData+0x20b [libre-office-git-repo\sw\source\core\ole\ndole.cxx @ 403] swlo!SwNodes::ChgNode+0x411 [libre-office-git-repo\sw\source\core\docnode\nodes.cxx @ 214] swlo!SwNodes::MoveNodes+0x18e6 [libre-office-git-repo\sw\source\core\docnode\nodes.cxx @ 868] swlo!SwUndoSaveContent::MoveToUndoNds+0x1c1 [libre-office-git-repo\sw\source\core\undo\undobj.cxx @ 784] swlo!SwUndoSaveSection::SaveSection+0x559 [libre-office-git-repo\sw\source\core\undo\undobj.cxx @ 1325] swlo!SwUndoSaveSection::SaveSection+0x55 [libre-office-git-repo\sw\source\core\undo\undobj.cxx @ 1278] swlo!SwUndoFlyBase::DelFly+0x127 [libre-office-git-repo\sw\source\core\undo\undobj1.cxx @ 232] swlo!SwUndoDelLayFormat::SwUndoDelLayFormat+0x64 [libre-office-git-repo\sw\source\core\undo\undobj1.cxx @ 429] swlo!std::make_unique+0x22 [C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\include\memory @ 3382] swlo!sw::DocumentLayoutManager::DelLayoutFormat+0x283 [libre-office-git-repo\sw\source\core\doc\DocumentLayoutManager.cxx @ 242] swlo!SwTextNode::DestroyAttr+0x82 [libre-office-git-repo\sw\source\core\txtnode\thints.cxx @ 1204] swlo!SwTextNode::EraseText+0x18f [libre-office-git-repo\sw\source\core\txtnode\ndtxt.cxx @ 2813] swlo!SwTextNode::DeleteAttributes+0x115 [libre-office-git-repo\sw\source\core\txtnode\thints.cxx @ 1863] swlo!SwXFrame::dispose+0xdb [libre-office-git-repo\sw\source\core\unocore\unoframe.cxx @ 2692] mscx_uno!`anonymous namespace'::cpp_call+0x710 [libre-office-git-repo\bridges\source\cpp_uno\msvc_win32_x86-64\uno2cpp.cxx @ 214] mscx_uno!unoInterfaceProxyDispatch+0x2fa [libre-office-git-repo\bridges\source\cpp_uno\msvc_win32_x86-64\uno2cpp.cxx @ 430] binaryurplo!binaryurp::IncomingRequest::execute_throw+0x635 [libre-office-git-repo\binaryurp\source\incomingrequest.cxx @ 239] binaryurplo!binaryurp::IncomingRequest::execute+0xbf [libre-office-git-repo\binaryurp\source\incomingrequest.cxx @ 79] binaryurplo!request+0x1c [libre-office-git-repo\binaryurp\source\reader.cxx @ 84] cppu3!cppu_threadpool::JobQueue::enter+0x21e [libre-office-git-repo\cppu\source\threadpool\jobqueue.cxx @ 101] cppu3!cppu_threadpool::ORequestThread::run+0xa0 [libre-office-git-repo\cppu\source\threadpool\thread.cxx @ 169] where the call to OleComponent::StoreOwnTmpIfNecessary from OleEmbeddedObject::StoreObjectToStream was made with m_aMutex held; and that mutex was attempted to be locked from the main thread, holding solar mutex. Change-Id: I1914188728cdaa9cdf22d216ec71f733d7780692 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175117 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-14Avoid deadlock because of recursive lockMike Kaganski
As seen in the following call stacks: Main thread sal3!osl_acquireMutex+0x49 [libre-office-git-repo\sal\osl\w32\mutex.cxx @ 65] emboleobj!osl::Mutex::acquire+0x9 [libre-office-git-repo\include\osl\mutex.hxx @ 63] emboleobj!osl::Guard<osl::Mutex>::{ctor}+0x9 [libre-office-git-repo\include\osl\mutex.hxx @ 144] emboleobj!OleEmbeddedObject::getCurrentState+0x68 [libre-office-git-repo\embeddedobj\source\msole\oleembed.cxx @ 643] sfxlo!SfxInPlaceClient::IsObjectUIActive+0x23 [libre-office-git-repo\sfx2\source\view\ipclient.cxx @ 847] sfxlo!SfxViewShell::GetUIActiveClient+0x5b [libre-office-git-repo\sfx2\source\view\viewsh.cxx @ 2521] sfxlo!SfxDispatcher::FindServer_+0x282 [libre-office-git-repo\sfx2\source\control\dispatch.cxx @ 1627] sfxlo!SfxDispatcher::GetShellAndSlot_Impl+0x2f [libre-office-git-repo\sfx2\source\control\dispatch.cxx @ 703] sfxlo!SfxDispatcher::QueryState+0x5b [libre-office-git-repo\sfx2\source\control\dispatch.cxx @ 1979] swlo!SwView::CheckReadonlyState+0x64 [libre-office-git-repo\sw\source\uibase\uiview\view.cxx @ 627] swlo!SwView::TimeoutHdl+0x76 [libre-office-git-repo\sw\source\uibase\uiview\view.cxx @ 608] vcllo!Scheduler::CallbackTaskScheduling+0x130e [libre-office-git-repo\vcl\source\app\scheduler.cxx @ 511] vclplug_winlo!WinSalTimer::ImplHandleElapsedTimer+0x2e [libre-office-git-repo\vcl\win\app\saltimer.cxx @ 167] vclplug_winlo!ImplSalYield+0x14f [libre-office-git-repo\vcl\win\app\salinst.cxx @ 525] vclplug_winlo!WinSalInstance::DoYield+0xad [libre-office-git-repo\vcl\win\app\salinst.cxx @ 581] vcllo!ImplYield+0x367 [libre-office-git-repo\vcl\source\app\svapp.cxx @ 393] vcllo!Application::Execute+0xfa [libre-office-git-repo\vcl\source\app\svapp.cxx @ 369] sofficeapp!desktop::Desktop::Main+0x173f [libre-office-git-repo\desktop\source\app\app.cxx @ 1605] vcllo!ImplSVMain+0xda [libre-office-git-repo\vcl\source\app\svmain.cxx @ 229] sofficeapp!soffice_main+0xf3 [libre-office-git-repo\desktop\source\app\sofficemain.cxx @ 94] Request thread sal3!osl_acquireMutex+0x49 [libre-office-git-repo\sal\osl\w32\mutex.cxx @ 65] vclplug_winlo!osl::Mutex::acquire+0xa [libre-office-git-repo\include\osl\mutex.hxx @ 63] vclplug_winlo!SalYieldMutex::doAcquire+0x91 [libre-office-git-repo\vcl\win\app\salinst.cxx @ 148] emboleobj!SolarMutexReleaser::{dtor}+0xc [libre-office-git-repo\include\vcl\svapp.hxx @ 1425] emboleobj!OleComponent::GetExtent+0x102 [libre-office-git-repo\embeddedobj\source\msole\olecomponent.cxx @ 1134] emboleobj!OleEmbeddedObject::getVisualAreaSize+0x23f [libre-office-git-repo\embeddedobj\source\msole\olevisual.cxx @ 227] emboleobj!OleEmbeddedObject::saveCompleted+0x406 [libre-office-git-repo\embeddedobj\source\msole\olepersist.cxx @ 1603] comphelper!comphelper::EmbeddedObjectContainer::StoreEmbeddedObject+0x49b [libre-office-git-repo\comphelper\source\container\embeddedobjectcontainer.cxx @ 501] comphelper!comphelper::EmbeddedObjectContainer::InsertEmbeddedObject+0x6f [libre-office-git-repo\comphelper\source\container\embeddedobjectcontainer.cxx @ 518] comphelper!comphelper::EmbeddedObjectContainer::RemoveEmbeddedObject+0x388 [libre-office-git-repo\comphelper\source\container\embeddedobjectcontainer.cxx @ 945] comphelper!comphelper::EmbeddedObjectContainer::RemoveEmbeddedObject+0x46 [libre-office-git-repo\comphelper\source\container\embeddedobjectcontainer.cxx @ 831] swlo!SwOLENode::SavePersistentData+0x20b [libre-office-git-repo\sw\source\core\ole\ndole.cxx @ 403] swlo!SwNodes::ChgNode+0x411 [libre-office-git-repo\sw\source\core\docnode\nodes.cxx @ 214] swlo!SwNodes::MoveNodes+0x18e6 [libre-office-git-repo\sw\source\core\docnode\nodes.cxx @ 868] swlo!SwUndoSaveContent::MoveToUndoNds+0x1c1 [libre-office-git-repo\sw\source\core\undo\undobj.cxx @ 784] swlo!SwUndoSaveSection::SaveSection+0x559 [libre-office-git-repo\sw\source\core\undo\undobj.cxx @ 1325] swlo!SwUndoSaveSection::SaveSection+0x55 [libre-office-git-repo\sw\source\core\undo\undobj.cxx @ 1278] swlo!SwUndoFlyBase::DelFly+0x127 [libre-office-git-repo\sw\source\core\undo\undobj1.cxx @ 232] swlo!SwUndoDelLayFormat::SwUndoDelLayFormat+0x64 [libre-office-git-repo\sw\source\core\undo\undobj1.cxx @ 429] swlo!std::make_unique+0x22 [C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\include\memory @ 3382] swlo!sw::DocumentLayoutManager::DelLayoutFormat+0x283 [libre-office-git-repo\sw\source\core\doc\DocumentLayoutManager.cxx @ 242] swlo!SwTextNode::DestroyAttr+0x82 [libre-office-git-repo\sw\source\core\txtnode\thints.cxx @ 1204] swlo!SwTextNode::EraseText+0x18f [libre-office-git-repo\sw\source\core\txtnode\ndtxt.cxx @ 2813] swlo!SwTextNode::DeleteAttributes+0x115 [libre-office-git-repo\sw\source\core\txtnode\thints.cxx @ 1863] swlo!SwXFrame::dispose+0xdb [libre-office-git-repo\sw\source\core\unocore\unoframe.cxx @ 2692] mscx_uno!`anonymous namespace'::cpp_call+0x710 [libre-office-git-repo\bridges\source\cpp_uno\msvc_win32_x86-64\uno2cpp.cxx @ 214] mscx_uno!unoInterfaceProxyDispatch+0x2fa [libre-office-git-repo\bridges\source\cpp_uno\msvc_win32_x86-64\uno2cpp.cxx @ 430] binaryurplo!binaryurp::IncomingRequest::execute_throw+0x635 [libre-office-git-repo\binaryurp\source\incomingrequest.cxx @ 239] binaryurplo!binaryurp::IncomingRequest::execute+0xbf [libre-office-git-repo\binaryurp\source\incomingrequest.cxx @ 79] binaryurplo!request+0x1c [libre-office-git-repo\binaryurp\source\reader.cxx @ 84] cppu3!cppu_threadpool::JobQueue::enter+0x21e [libre-office-git-repo\cppu\source\threadpool\jobqueue.cxx @ 101] cppu3!cppu_threadpool::ORequestThread::run+0xa0 [libre-office-git-repo\cppu\source\threadpool\thread.cxx @ 169] As seen, the request thread has OleEmbeddedObject::saveCompleted and OleEmbeddedObject::getVisualAreaSize on the stack; both acquire OleEmbeddedObject's mutex; but only getVisualAreaSize releases it for the call of OleComponent::GetExtent. The latter releases solar mutex, at which time, the main thread (locking the solar mutex) attempts to call OleEmbeddedObject::getCurrentState, which needs the object's mutex, which is still locked in the request thread. Avoid this, by passing the lock object to the implementation of getVisualAreaSize from saveCompleted. Change-Id: Ie44a20a8c89000e0e951e024c2bfde93cf2cc3f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174891 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-08-22Make OleEmbeddedObject locking stricterMike Kaganski
This is an attempt to reduce areas that execute with mutex unlocked because the called code may deadlock. Also, this copies objects on stack before unlocking, using lambdas' own variables. I hope that it somewhat improves reliability. OTOH, this runs more code with lock active, has a potential of new deadlocks, so risky. Change-Id: I558b7f5f18f63622fed3a9c3978327d0d76fe90d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172237 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-08-14Unlock the mutex to avoid deadlockMike Kaganski
The request thread was calling OleComponent::CloseObject, which executed on main thread; OleEmbeddedObject::m_aMutex as locked by request thread: emboleobj.dll!OleComponent::CloseObject() Line 1004 emboleobj.dll!OleComponent::Dispose() Line 451 emboleobj.dll!OleComponent::close(unsigned char bDeliverOwnership) Line 1513 emboleobj.dll!OleEmbeddedObject::GetRidOfComponent() Line 235 emboleobj.dll!OleEmbeddedObject::Dispose() Line 269 emboleobj.dll!OleEmbeddedObject::close(unsigned char bDeliverOwnership) Line 498 comphelper.dll!comphelper::EmbeddedObjectContainer::CloseEmbeddedObjects() Line 208 sfxlo.dll!SfxObjectShell::~SfxObjectShell() Line 322 swlo.dll!SwDocShell::~SwDocShell() Line 380 swlo.dll!SwDocShell::`vector deleting destructor'(unsigned int) cppuhelper3MSC.dll!cppu::OWeakObject::release() Line 229 sfxlo.dll!rtl::Reference<SfxObjectShell>::~Reference<SfxObjectShell>() Line 126 sfxlo.dll!IMPL_SfxBaseModel_DataContainer::~IMPL_SfxBaseModel_DataContainer() Line 265 sfxlo.dll!IMPL_SfxBaseModel_DataContainer::`scalar deleting destructor'(unsigned int) sfxlo.dll!std::_Destroy_in_place<IMPL_SfxBaseModel_DataContainer>(IMPL_SfxBaseModel_DataContainer & _Obj) Line 293 sfxlo.dll!std::_Ref_count_obj2<IMPL_SfxBaseModel_DataContainer>::_Destroy() Line 2113 sfxlo.dll!std::_Ref_count_base::_Decref() Line 1164 sfxlo.dll!std::_Ptr_base<IMPL_SfxBaseModel_DataContainer>::_Decref() Line 1380 sfxlo.dll!std::shared_ptr<IMPL_SfxBaseModel_DataContainer>::~shared_ptr<IMPL_SfxBaseModel_DataContainer>() Line 1685 sfxlo.dll!std::shared_ptr<IMPL_SfxBaseModel_DataContainer>::reset() Line 1732 sfxlo.dll!SfxBaseModel::dispose() Line 794 swlo.dll!SwXTextDocument::dispose() Line 561 sfxlo.dll!SfxBaseModel::close(unsigned char bDeliverOwnership) Line 1523 swlo.dll!SwXTextDocument::close(unsigned char bDeliverOwnership) Line 574 sfxlo.dll!SfxBaseModel::dispose() Line 745 swlo.dll!SwXTextDocument::dispose() Line 561 mscx_uno.dll!`anonymous namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis, bridges::cpp_uno::shared::VtableSlot aVtableSlot, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs, _uno_Any * * ppUnoExc) Line 214 mscx_uno.dll!unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberTD, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 430 binaryurplo.dll!binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny * returnValue, std::vector<binaryurp::BinaryAny,std::allocator<binaryurp::BinaryAny>> * outArguments) Line 239 binaryurplo.dll!binaryurp::IncomingRequest::execute() Line 79 binaryurplo.dll!request(void * pThreadSpecificData) Line 84 cppu3.dll!cppu_threadpool::JobQueue::enter(const void * nDisposeId, bool bReturnWhenNoJob) Line 101 cppu3.dll!cppu_threadpool::ORequestThread::run() Line 165 cppu3.dll!threadFunc(void * param) Line 190 sal3.dll!oslWorkerWrapperFunction(void * pData) Line 67 Main thread was acquiring OleEmbeddedObject::m_aMutex, which deadlocked: sal3.dll!osl_acquireMutex(_oslMutexImpl * Mutex) Line 65 emboleobj.dll!osl::Mutex::acquire() Line 63 emboleobj.dll!osl::ResettableGuard<osl::Mutex>::reset() Line 250 emboleobj.dll!OleEmbeddedObject::setVisualAreaSize(__int64 nAspect, const com::sun::star::awt::Size & aSize) Line 148 swlo.dll!SwWrtShell::CalcAndSetScale(svt::EmbeddedObjectRef & xObj, const SwRect * pFlyPrtRect, const SwRect * pFlyFrameRect, const bool bNoTextFramePrtAreaChanged) Line 777 swlo.dll!SwContentNotify::ImplDestroy() Line 926 swlo.dll!SwContentNotify::~SwContentNotify() Line 1037 swlo.dll!SwNoTextFrame::MakeAll(OutputDevice * pRenderContext) Line 584 swlo.dll!SwFrame::OptPrepareMake() Line 412 swlo.dll!SwFrame::OptCalc() Line 1110 swlo.dll!SwLayAction::FormatContent_(const SwContentFrame * pContent, const SwPageFrame * pPage) Line 1960 swlo.dll!SwLayAction::FormatFlyContent(const SwFlyFrame * pFly) Line 1985 swlo.dll!SwObjectFormatter::FormatObj_(SwAnchoredObject & _rAnchoredObj) Line 312 swlo.dll!SwObjectFormatterTextFrame::DoFormatObj(SwAnchoredObject & _rAnchoredObj, const bool _bCheckForMovedFwd) Line 133 swlo.dll!SwObjectFormatter::FormatObjsAtFrame_(SwTextFrame * _pMasterTextFrame) Line 414 swlo.dll!SwObjectFormatterTextFrame::DoFormatObjs() Line 348 swlo.dll!SwObjectFormatter::FormatObjsAtFrame(SwFrame & _rAnchorFrame, const SwPageFrame & _rPageFrame, SwLayAction * _pLayAction) Line 160 swlo.dll!SwLayAction::FormatContent(SwPageFrame * pPage) Line 1793 swlo.dll!SwLayAction::InternalAction(OutputDevice * pRenderContext) Line 605 swlo.dll!SwLayAction::Action(OutputDevice * pRenderContext) Line 389 swlo.dll!SwLayIdle::SwLayIdle(SwRootFrame * pRt, SwViewShellImp * pI) Line 2363 swlo.dll!SwViewShell::LayoutIdle() Line 827 swlo.dll!sw::DocumentTimerManager::DoIdleJobs(Timer * __formal) Line 176 swlo.dll!sw::DocumentTimerManager::LinkStubDoIdleJobs(void * instance, Timer * data) Line 156 vcllo.dll!Link<Timer *,void>::Call(Timer * data) Line 111 vcllo.dll!Timer::Invoke() Line 75 vcllo.dll!Scheduler::CallbackTaskScheduling() Line 509 vcllo.dll!SalTimer::CallCallback() Line 53 vclplug_winlo.dll!WinSalTimer::ImplHandleElapsedTimer() Line 169 vclplug_winlo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 525 vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 581 vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents) Line 385 vcllo.dll!Application::Yield() Line 473 vcllo.dll!Application::Execute() Line 361 sofficeapp.dll!desktop::Desktop::Main() Line 1652 vcllo.dll!ImplSVMain() Line 229 vcllo.dll!SVMain() Line 262 sofficeapp.dll!soffice_main() Line 110 soffice.bin!sal_main() Line 51 soffice.bin!main(int argc, char * * argv) Line 49 soffice.bin!invoke_main() Line 79 soffice.bin!__scrt_common_main_seh() Line 288 soffice.bin!__scrt_common_main() Line 331 soffice.bin!mainCRTStartup(void * __formal) Line 17 Change-Id: Iaf5133c488d4f26f43530ea19584e99cce12d81e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171855 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-04-04Use osl::ResettableMutexGuardScopedReleaser instead of ad-hoc guardsMike Kaganski
Change-Id: I2aa09655c207d3647650b5e38011a600bd221699 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165777 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-19Release the mutex when calling the OLE methodMike Kaganski
... which may need to be executed on a different thread. Change-Id: Id9e4b86fd3eafa49139b21e3817aa1ee8aff3dba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164986 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-13Introduce a guard to delay processing of idlesMike Kaganski
In a following scenario, there could be a crash: 1. Platform: a Windows system with MS Word installed. 2. LibreOffice is run in a listener mode; 3. A Java program opens a Writer document in a visible mode, with an embedded Word OLE object; 4. It adds some text; then resizes the OLE object; then removes the OLE object. Word OLE objects have OLEMISC_RECOMPOSEONRESIZE flag [1]; this means, that every re-layout of the document with this object must ask the OLE server to re-layout the object content. So, the request thread changes the document text, which triggers idle re-layout or redraw; the idles start executing immediately in the idle main thread, with solar mutex locked; then the request thread starts the OLE object removal operation. The ongoing relayout in main thread would at some stage need to execute a call to the OLE object, which temporarily releases the solar mutex (this makes impossible using solar mutex to synchronize the order of operations in this scenario). Other mutexes guarding OLE object (in OleEmbeddedObject, and in OleComponent) are also released for the duration of the call. Thus, the removal that happens in the request thread proceeds, and the node containing the OLE object is destroyed, while the main thread (processing exactly this node) is waiting for the OLE server response, then for mutexes, to proceed. After that, the main thread would attempt to access the destroyed node object. This change introduces a scheduler guard (a RAII object), that sets a flag to not process idle events during the lifetime of the guard. In its constructor, it also makes sure, that current pending idle events are finished. This would make sure that guarded code started from other threads would not race with idles potentially accessing the model that is currently in transient state. [1] https://learn.microsoft.com/en-us/windows/win32/api/oleidl/ne-oleidl-olemisc Change-Id: I2ef0601ccd8b5872588a88493d1f43e39022dbed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164753 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-11Reimplement OleComponentNative_Impl to use IGlobalInterfaceTableMike Kaganski
... to make sure that object methods are called in correct apartment The user-visible problem was, that running a Java code that connects to LibreOffice, and opening a document with an embedded OLE object (it was Word object in a specific case, which needs activation at opening stage, because these objects have OLEMISC_RECOMPOSEONRESIZE flag), using loadComponentFromURL with "OnMainThread" set to true, then closing the document, resulted in a hang after several hundreds iterations. This was caused by Word process, that was started in background to serve the COM calls, wasn't closed properly, and kept all the objects in memory, until OOM. The reason why it wasn't closed was failed call to IOleObject::Close in OleComponent::CloseObject, which returned RPC_E_WRONG_THREAD, because the activation of the OLE object happened in the main thread (because of "OnMainThread"), which is STA, but closing happened in the handler thread (belonging to MTA). Similar problems previously were addressed in commits 2dc3a6c273cb82506842864481d78df7294debbf (framework: allow loading a component on the main thread, 2018-12-20), 6002014ce0a5c9cea22c14b2437b7a508b2c72cb (framework: allow loading a component on the main thread, using XDesktop, 2021-04-28), d5cd62164d32273a25913c93aa04be9f7f3a4073 (embeddedobj: handle getting the visible area on a thread, 2021-05-07). These changes tried different workarounds for the same problem, when a COM object instantiated in one apartment is later manipulated from another, which fails. First two handled the case when the document is loaded from a non-UI thread, and then manipulated with the UI; to handle that, they introduced flags that delegated opening the file to the main (UI) thread. The last change tried to handle the reverse problem of the OLE object instantiated in the main thread was saved in a handler thread, which again failed; the workaround was, again, to try to delegate the second attempt to the main thread. But basically all methods can fail in such circumstations, as shown in this problem's case. The "OnMainThread" flag must be passed to fileopen functions explicitly. Also, the workarounds only work by passing everything to STA, and don't target a case when the calls must be passed from STA to MTA. Since Windows 2000, there is IGlobalInterfaceTable, which goal is to solve this problem. It allows to use an intermediate object, which can transparently delegate all calls to the correct thread. This change re-implements how OLE objects are referenced from OleComponentNative_Impl, using the said IGlobalInterfaceTable. This should hopefully obsolete the previous workarounds, which nevertheless are kept for now. Change-Id: Ia1c590e547ed24a2c7389283aed6cc3d8ea024b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164457 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-12-29add some more libraries to libmergedNoel Grandin
and fix some resulting symbol name clashes Change-Id: I57b11494742ef74a97e0afb294b4e44813eaa249 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161074 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-12-21make use of toplevel docmodel's UserAllowsLinkUpdate propertyCaolán McNamara
Change-Id: Ia560c123c2f9dd08acb7eeaafccee332dd16300e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161133 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-10-12Make NC_ constexpr-friendlyStephan Bergmann
...by moving the char8_t -> char reinterpret_cast out of any potential constexpr paths into a new TranslateId::getId. And demonstrate constexpr'ability by making the aCategories var in OApplicationIconControl::Fill (dbaccess/source/ui/app/AppIconControl.cxx) constexpr. (And there might be more such cases that could now be made constexpr.) Change-Id: I0b4e3292faf8f6b901f9b9e934e1aa6bf0f583ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157862 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-04-14add a route to get writer Floating Frame links under 'manage links'Caolán McNamara
Change-Id: If90ff71d6a96342574799312f764badaf97980eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150349 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-04-13extract a OCommonEmbeddedObject::SetInplaceActiveState for reuseCaolán McNamara
no behaviour change intended Change-Id: Ia1d12aa5c9afdc1347f6d4364bc6a0b7f41ee168 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150341 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-04-03set a parent for embedded object warning dialogCaolán McNamara
calc does a lot of "CaptureMouse" which then leads to a lot of "ReleaseMouse", I'm somewhat unconvinced that there should be any CaptureMouse calls in there. Change-Id: I7c44d2c36c89a5c32c525d65939723da9be77a72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149973 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-01-05Revert all the recent loplugin:unocast changesStephan Bergmann
...as obsoleted by ef533553559fe09b4afab651fc692885d1acf4ed "Rudimentary support for dynamic_cast on UNO proxy objects". This reverts all of: 4cfcc9ac37b90ce64c8402a41eb4638adb185b5c "loplugin:unocast (framework::Desktop)" 03efbf72f4ddf7a84aa8aabef348331bd4b75e8a "loplugin:unocast (vclcanvas::TextLayout)" 80099fdd51a69eaa6c36ca88ef772810e4a777fa "loplugin:unocast (SalGtkXWindow)" cc147f576d8687fb79c77d47d41dc4ba1678a469 "loplugin:unocast (sdext::presenter::CachablePresenterView)" 40db42be1d8fd0f9c6c8c5ba3767ddb9ee2034c2 "loplugin:unocast (vclcanvas::CanvasFont)" 2d1e7995eae29e2826449eb5179f5fae181794a5 "loplugin:unocast (CairoColorSpace)" 4c0bbe4bd97636207cf71a6aa120c67698891da9 "loplugin:unocast (canvas::ParametricPolyPolygon)" 89803666621c07d1b1ac9d3bd883f0ca192a91a0 "loplugin:unocast (vclcanas::CanvasBitmap)" d5e0c2c8db71878d21c2a7255af08cf5f9a6dd04 "loplugin:unocast (sfx2::DigitalSignatures)" c0c4519e0d5b555f59bbc04cc616454edfd1f4ce "loplugin:unocast (VCLXAccessibleComponent)" feb8b833a6245d42400f42a0bc789dc84594ee6f "loplugin:unocast (VCLXDialog)" 1fa58cc6cc9c3849753342a5d9a6ddfa461b5e66 "loplugin:unocast (VCLXMultiPage)" f481f036deb1b1b46f3038074c4659f3a91b9c6c "loplugin:unocast (DocumentSettingsSerializer)" 73df933f5fa5932f94e5a1b338a3eda00a9ce354 "loplugin:unocast (css::embed::EmbeddedUpdate)" 420165ab0ef03c0467f9d17f504de2d2fc78f0e6 "loplugin:unocast (canvas::tools' StandardColorSpace, StandardNoAlphaColorSpace)" 9abe8ee067e6c00f19d8a13346d53c4641c27166 "loplugin:unocast (MutableTreeNode)" 9f3022ceb036f23b4b0994c3e2fbd1001bff225a "loplugin:unocast (VCLXTabPage)" 1be70dda02c12a60778b7607cff2520ae1aa611e "loplugin:unocast (vcl::unotools::VclCanvasBitmap)" d6a70bb641b96e8e5616448c2378131ed62658b4 "loplugin:unocast (basegfx::unotools::UnoPolyPolygon)" 5a14f009e6782c077463c8cbb8e9cea3d7950107 "loplugin:unocast (xmlsecurity::Certificate)" 99009c9535dfa3e0d838989ccc7d84bfa2320ff4 "loplugin:unocast (sd::Annotation)" 0c7585c5fa78887e5459885ed744e8044fd76137 "loplugin:unocast (sd::TextApiObject)" 24e14afd1bfcaed6c200ab081973fba7e47267ca "loplugin:unocast (SignatureVerifierImpl)" 1a7ad0c10d286ce9ae2700ceb2fd50eed1fb43a4 "loplugin:unocast (pcr::PropertyEventTranslation)" a97e2d2702d9a6f37775ccee2c08c4f3b2479c4b "loplugin:unocast (RangePageBreaks)" 19dfdf86ad1f5b08041d8b7a9f196caf881231ab "iloplugin:unocast (pcr::OFormattedNumericControl)" f9785ea595fd8e911f6370e836fa579225b9e571 "loplugin:unocast (frm::OInterfaceContainer)" 5e5f40a4a92a31b0932c690219d002fcf18598cf "loplugin:unocast (ScVbaShapes)" 27b35b2c215b4832d4378ec3a7ecbba926552d06 "loplugin:unocast (ScVbaShapeRange)" cb3108f860065928552a86cf8acc4b3a95718ecf "cid#1517812 Dereference null return value" feba0ddb1521d1142560fe54b7d7696ee910237f "loplugin:unocast (weld::TransportAsXWindow)" 4d6c23216559eb48f9943bb49d6e475a6d64ba15 "loplugin:unocast (oox::ForumlaImExportBase)" 4844c096a8ab6a9a620c410a0949d4499f12a504 "loplugin:unocast (cairocanvas::SurfaceProvider)" 9a0b523e0a84d403b9092176ccec4b3e3efe42d0 "loplugin:unocast (cairocanvas::CanvasBitmap)" 8a5648d8e59b4b007dbbf3824777c19a21efc61e "loplugin:unocast (cairocanvas::TextLayout)" 28c27a0623bc78a0590858f97d03b620985bc84c "loplugin:unocast (cairocanvas::CanvasFont)" 53bc223cb3288e32a417696ee61c29e5f01f209d "loplugin:unocast (cairocanvas::RepaintTarget)" 5f70b0b9f6bc4ab145ddbd9155590ed4a3b1b9ec "loplugin:unocast (SvXMLImport)" 068187a898cdd2e26e9b16c348ecc1ed2dee3f29 "loplugin:unocast (VCLXWindow)" 88b4f966202717cd4ad38a30a8eda22c3e69ed35 "loplugin:unocast (sfx2::sidebar::SidebarController)" f1b7a69b280aefe2f1b3b0f32193494fd765f2bd "loplugin:unocast (SvxLineStyleToolBoxControl)" ba76f0ba7e8de4d2953739c952004b7d9af47197 "loplugin:unocast (i18npool::Calendar_gregorian)" 840154daf934d8df52ead1cb7acd798c4d30f007 "loplugin:unocast (framework::AddonsToolBarWrapper)" b0e9c4c5f063cefa9557810e3349bdb9c7493091 "loplugin:unocast (GrammarCheckingIterator)" 8ee6cfc9655ce9de4617cea1a0d9cb9d7a4fbfac "loplugin:unocast (ucb::ucp::ext::Content)" 5b8cd77c112bc8c0e92b8fec215c3c8e802bbc0a "loplugin:unocast (basic::SfxScriptLibraryContainer)" 9e73ff9fce12e102bb3c3cea8d8bb96c88f2c9ad "loplugin:unocast (sdext::presenter::PresenterNotesView)" a98acca8fbc38d3fd5600ae5056a8e42b6d8a40d "loplugin:unocast (SelectionChangeHandler)" c0b59ad6e35b0cb0dea0821e95f95569739078c1 "Consistently use comphelper::getSomethingImpl<I>(aIdentifier, this)" 276e3ccbdd3259ec3daf8a1a98fa7f406b14e21c "loplugin:unocast (vclcanvas::RepaintTarget)" Change-Id: I37c73e3422a5154bf6cb647640d2d3f23db8bc34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145063 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22loplugin:unocast (css::embed::EmbeddedUpdate)Stephan Bergmann
(See the upcoming commit introducing that loplugin:unocast on why such dynamic_casts from UNO types are dangerous.) Change-Id: Ia0f628be9adf749ffdd9ad36ca9b1e8c98e29936 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144755 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-06-21clang-tidy modernize-pass-by-value in embeddedobjNoel Grandin
Change-Id: I5ed8591a3c3ae58d5ddf921814b8d7a373f9c76e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136202 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-24this data does not need to be per-objectNoel Grandin
Change-Id: I7cf9486d80be103c2e9affd805c7bdac46fafe9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134838 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-10tdf#147590 update OLE object after document refreshJuergen Funk
Regression from b099da78a6f0b3e120f706714003b05d84d11e70 we didn't update linked OLE document after document reload Change-Id: I8e52f6430f454b276cb43449c6f7a3b0e07e909f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130692 Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Tested-by: Jenkins
2021-11-26sw, viewing OLE objects: also protect "common" embeded objectsMiklos Vajna
Commit 4f9f1ac33366817df61c488a9f36b09c592ee939 (sw: allow viewing OLE objects in protected sections, 2021-11-25) allowed launching OLE objects in protected sections, and then made sure that changes done in "real" OLE editors (on Windows) are discarded: both the native data and preview. Extend this mechanism to also handle common embedded objects (i.e. when we load the data into an own document model, like Calc-in-Writer on Linux): there we can simply load the data read-only, so there will be no need to discard anything. This requires some way to pass down the read-only flag from sw/ to embeddedobj, implement XInitialization on OCommonEmbeddedObject to do that. Change-Id: I7b32d7514a6b0a40b4f58bed57879d292daa4ed7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125858 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-10-30Prepare for removal of non-const operator[] from Sequence in embeddedobjMike Kaganski
Change-Id: I19432a1e506526fdc1cd98625d9cfff12ea2f973 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124361 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-10embeddedobj: implement XServiceInfo in the various embedded obj implementationsMiklos Vajna
This gives UNO clients a reliable way to detect e.g. OSpecialEmbeddedObject, where it's expected that double-clicking on the object doesn't do anything. Change-Id: I595453490b157b64214cd7359da1e3a3c959191d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120274 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-08-07create comphelper::OMultiTypeInterfaceContainerHelper2 and use itNoel Grandin
based on OInterfaceContainerHelper2 which is considerably faster than the original OInterfaceContainerHelper Change-Id: I9c8b6d0e5382018824bf7188a26343703abf2d51 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120161 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-02throw() -> noexcept, part 2/3: Automatic loplugin:noexcept rewriteStephan Bergmann
Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-08tdf#141529 sync linked OLE save(s) with hosting file save(s)Armin Le Grand (Allotropia)
Before deactivating a linked OLE saved it and overwrote the original, even when not saving the hosting document at all. This is not intuitive from user perspective and may lead to unexpected data loss (of the OLE content). Reported case was especially about closing the hosted document without saving in the understandable believe that that way the changed OLE will not be changed on external medium. Added mechanism for linked OLE to hold data in a hidden local temp file, synching/writing back on hosting file save. Most complicated was adapting the 'break link' case and ensuring other cases to work, but looks good now from my POV Change-Id: I7f63d667820b2d9725abc598a9dd7360be1f8d5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113793 Tested-by: Armin Le Grand <Armin.Le.Grand@me.com> Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-03-20use unique_ptr in OCommonEmbeddedObjectNoel Grandin
Change-Id: I2258838cbbe242dbe31500ecd6f29c315a335b71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112743 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-03loplugin:refcounting (clang-cl)Stephan Bergmann
Change-Id: Ifa54eed0a772b658d266e9e42be5f5232e7a6b79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111812 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-12tdf#42949 Fix new IWYU warnings in directories [e-f]*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I963aa5fb892a0be36212fd0587b69f217f017947 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105469 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-13tdf#124176 Use #pragma once in embeddedobjGeorge Bateman
This commit was carried out by a Python script, source of which is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97. Change-Id: Ia481a860be174b817106ac13eccb5e53ee070aec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102577 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-07-22embeddedobj/msole: create instances with uno constructorsNoel Grandin
See tdf#74608 for motivation. Change-Id: I11ad7cf96d65332e418f1854803d62a30bacc7e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99163 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-22embeddedobj/util: create instances with uno constructorsNoel Grandin
See tdf#74608 for motivation. Change-Id: I52734cc1420ae7915da3191cf94ac61287a0983a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99162 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-08compact namespace in editeng..extensionsNoel Grandin
Change-Id: Ie93ac69592c3625b8e2e5db3619ce24597a07a7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93722 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-07m_aVerbTable can be a std::mapNoel Grandin
instead of using the heavyweight Sequence datastructures Change-Id: Ica6b30490f2a1b4367acbf0341ecc86701c21926 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93641 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-11tdf#42949 Fix IWYU warnings in embeddedobj/Gabor Kelemen
Except for test/ which seems to be unused anyway Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I9d0b75dbb260f05390b513be75a4bdd24647c91b Reviewed-on: https://gerrit.libreoffice.org/80077 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-09-26loplugin:constmethod in embeddedobj..extensionsNoel Grandin
Change-Id: Iec6a9ff8b62ac1986cca205435273b64b71f33cd Reviewed-on: https://gerrit.libreoffice.org/79539 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-05-22Fix typoAndrea Gelmini
Change-Id: I627d0d9899226eb39a19bde1ecf79f04ca26e633 Reviewed-on: https://gerrit.libreoffice.org/72717 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2018-11-15Fix typoAndrea Gelmini
Change-Id: I9ccd24ad6baf3e3ebe6c988ad14df0f5f7c96ca0 Reviewed-on: https://gerrit.libreoffice.org/63392 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2018-11-14sw: fix modification of ole obj native data during HTML importMiklos Vajna
It is expected that if you load an OLE2 storage (from reqif-xhtml) and you save it as ODT, the OLE2 data is not modified. This was almost the case, but we insisted on removing the OLE2 preview from the storage. Add a new flag to OleEmbeddedObject, so import filters can opt in for not modifying the OLE2 data. [ The nice situation is that we already had a test file which had a preview stream in the OLE2 storage, so we can easily assert there that the size doesn't change. ] Change-Id: I9b8b29f015dd4f2513e51a1066767218580cb5d8 Reviewed-on: https://gerrit.libreoffice.org/63381 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2018-06-05tdf#42949 remove unused compheler includes ..Jochen Nitschke
and fix the fallout Change-Id: I15bc5d626f4d157cbc69a87392078b41e621d14e Reviewed-on: https://gerrit.libreoffice.org/54882 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-05-30sw HTML filter: handle embedded ODF content in xhtml/reqif modeMiklos Vajna
Embedded native data (what we don't parse just carry on) and real OLE2 embedding already worked, this adds the case where the actual content is ODF, just inside OLE2. The DOC import/export had support for handleing ODF content inside OLE2, so reuse that code: add new functions to SvxMSDffManager for import purposes and reuse SvxMSExportOLEObjects for export purposes. Change-Id: I0acf65d4bf29af896b8f1dd625e8672050aae350 Reviewed-on: https://gerrit.libreoffice.org/55088 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2018-05-30embeddedobj: document OCommon/DummyEmbeddedObjectMiklos Vajna
Change-Id: Ia0024945fa88c14dce4da571ddfd3281e1e41da7 Reviewed-on: https://gerrit.libreoffice.org/55022 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-05-07loplugin:useuniqueptr in OleEmbeddedObjectNoel Grandin
Change-Id: Ia455b86ec14320234935bce32c0bc33a88db036a Reviewed-on: https://gerrit.libreoffice.org/53875 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-03-23sw XHTML import: support OLE2-in-RTF objectsMiklos Vajna
If you like layering things on top of each other, then this commit message is for you. So it's possible to have a PPTX file in the following wrappers: - wrap PPTX in a binary OLE2 container - wrap that in an OLE1 container - wrap that in an RTF fragment - wrap that in an XHTML fragment (in a ReqIF file) Turns out that only the RTF and OLE1 unwrapping was missing, the rest worked already, so implement the missing piece in a new SwReqIfReader namespace. Finally extend OleEmbeddedObject to be able to read its native data stream when the object is opened, reading it from the storage would fail, as the object already opened the storage stream. Change-Id: I2934c9fb7474e981ff6bb2f7eb253a3a86cfd98b Reviewed-on: https://gerrit.libreoffice.org/51772 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-12-29loplugin:passstuffbyref improved return in variousNoel Grandin
Change-Id: I0a8282d8e0d9575b055243073fc89a7d6b67b560 Reviewed-on: https://gerrit.libreoffice.org/47173 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-12-14No need to keep these whitelisted functions decorated with SAL_CALLStephan Bergmann
The only effect SAL_CALL effectively has on LO-internal code is to change non- static member functions from __thiscall to __cdecl in MSVC (where all other functions are __cdecl by default, anyway). (For 3rd-party code, it could be argued that SAL_CALL is useful on function declarations in the URE stable interface other than non-static member functions, too, in case 3rd-party code uses a compiler switch to change the default calling convention to something other than __cdecl. But loplugin:salcall exempts the URE stable interface, anyway.) One could argue that SAL_CALL, even if today it effectively only affects non- static member functions in MSVC, could be extended in the future to affect more functions on more platforms. However, the current code would already not support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c "loplugin:salcall fix functions" changed FrameControl_createInstance in UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even though its address (in ctl_component_getFacrory, in the same file) is passed to cppuhelper::createSingleFactory as an argument of type cppu::ComponentInstantiation, which is a pointer to SAL_CALL function. Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6 Reviewed-on: https://gerrit.libreoffice.org/46436 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-07-18Embedded documents: show title in menu entriesSzymon Kłos
Change-Id: I478d81798e6f1e2d96e570cb6788a438c6a0be62 Reviewed-on: https://gerrit.libreoffice.org/40079 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
2017-07-13Show document title for embedded documentsSzymon Kłos
Embedded documents had "Untitled" name. This patch shows "<root document> (Embedded document)" string in the title bar. Change-Id: I6283240415f9e0c07c4c69672732a7c14eea9f5d Reviewed-on: https://gerrit.libreoffice.org/39835 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-07-13tdf#108545 tdf#108544: DOCX, XLSX embedded in DOCSzymon Kłos
When on Windows the MSO wasn't installed DOCX and XLSX embedded documents weren't accessible. General OLE error was shown after doubleclick on the object. Linux solution is reused, OLE storage is extracted to get the document inside. Change-Id: If4d00fddad8e127fcf1a222836896d2907549d0c Reviewed-on: https://gerrit.libreoffice.org/39814 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-04-21remove unnecessary explicit linefeeds from end of SAL and OSL log callsNoel Grandin
Change-Id: I3fa363c8e76e6cfb297f4ec346e3f031c09d6fbf Reviewed-on: https://gerrit.libreoffice.org/36727 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-01-26Remove dynamic exception specificationsStephan Bergmann
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-10 12:55:29 +0000