Description: When open a file with libre office the program do not response in several time, arown 5 minutes. When the documents are opened the program is very slowly. Other cases the libreoffice never open, is necesary to aply a kill to the proces. When try to convert some file to PDF there are two situatios: 1- The document never is transformed 2- The process is waiting arown ten minutes until it finishes Steps to Reproduce: 1.Open file with libreoffice 2.Export to PDF 3.The documents is scrolling Actual Results: 1.The libre office never open 2. The libre office is very slowly 3. The transformation to PDF in very slowly 4. The transformation to PDF never finished Expected Results: 1. Open the document 2. transform the document to PDF Reproducible: Always User Profile Reset: No Additional Info: The problem is present: 1.Is usually in documents from Microsof Office 2.Is usually in documents with contents of tables, images and other macros 3.The problem in present in versions 6 and 7 inclusive in 7.3.3 Attachment Link whith some problems documents: https://alfresco.greencore.co.cr/share/s/0vwc0yT6TEKIx-TgTMdqHw
To be importan to mention that during the fail process of transformation to PDF the CPU is exalted and affect the function of other process. For this reason is necessary to kill manually the libreoffice process.
What's the LO version? Last one are 7.2.7 or brand new 7.3.3 Also, could you give a try at https://wiki.documentfoundation.org/QA/FirstSteps ?
The documents are testing in version 6.1.6, 7.2.5 and 7.3.3
[Automated Action] NeedInfo-To-Unconfirmed
Please consider rules of Bugzilla: - one issue per report - reporting after the search in existing bugs - specific issue, with sample document and steps and results - sample file attached here, not in a link
It seems the first pb here to fix is the layout bug (see https://bugs.documentfoundation.org/show_bug.cgi?id=132261) Indeed, I gave a try with the zip. For UNA-CIGA-RA-MINU-007-2021_25_AGOSTO.doc I got this repeated log: warn:legacy.osl:277238:277238:sw/source/core/layout/flowfrm.cxx:2575: <SwFlowFrame::MoveBwd(..)> - layout loop control for layout action <Move Backward> applied! bt: #0 SwFlowFrame::MoveBwd(bool&) (this=0x6c66530, rbReformat=@0x7ffea364daef: false) at sw/source/core/layout/flowfrm.cxx:2575 #1 0x00007f581ec49deb in SwContentFrame::MakeAll(OutputDevice*) (this=0x6c66410) at sw/source/core/layout/calcmove.cxx:1536 #2 0x00007f581ec41e2a in SwFrame::OptPrepareMake() (this=0x6c66410) at sw/source/core/layout/calcmove.cxx:399 #3 0x00007f581ecc6326 in SwFrame::OptCalc() const (this=0x6c66410) at sw/source/core/inc/frame.hxx:1084 #4 0x00007f581ecc183f in SwLayAction::FormatContent_(SwContentFrame const*, SwPageFrame const*) (this=0x7ffea364e948, pContent=0x6c66410, pPage=0x9c5d770) at sw/source/core/layout/layact.cxx:1887 #5 0x00007f581ecbe9fe in SwLayAction::FormatContent(SwPageFrame*) (this=0x7ffea364e948, pPage=0x9c5d770) at sw/source/core/layout/layact.cxx:1708 #6 0x00007f581ecbc11a in SwLayAction::InternalAction(OutputDevice*) (this=0x7ffea364e948, pRenderContext=0x68b5bb0) at sw/source/core/layout/layact.cxx:778 #7 0x00007f581ecbac7a in SwLayAction::Action(OutputDevice*) (this=0x7ffea364e948, pRenderContext=0x68b5bb0) at sw/source/core/layout/layact.cxx:388 #8 0x00007f581ecc3d07 in SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) (this=0x7ffea364eaf8, pRt=0x689b6f0, pI=0x689da00) at sw/source/core/layout/layact.cxx:2267 #9 0x00007f581f50cffe in SwViewShell::LayoutIdle() (this=0x689aa20) at sw/source/core/view/viewsh.cxx:821 #10 0x00007f581e786c5d in sw::DocumentTimerManager::DoIdleJobs(Timer*) (this=0x677e1a0) at sw/source/core/doc/DocumentTimerManager.cxx:176 #11 0x00007f581e7862cd in sw::DocumentTimerManager::LinkStubDoIdleJobs(void*, Timer*) (instance=0x677e1a0, data=0x677e1b8) at sw/source/core/doc/DocumentTimerManager.cxx:156 Same logs for UNA-CIGA-RA-MINU-007-2021_25_AGOSTO.doc. For UNA-EI-OFIC-264-2022.doc Long to open (I didn't wait for the end) and noticed this repeated log: warn:legacy.osl:277636:277636:sw/source/core/layout/layact.cxx:574: LoopControl_1 in SwLayAction::InternalAction Now I don't know if we consider this one as a dup of existing one or do we add it to the meta bug, or something else. Michael: I know that layout pb isn't new but do we know the root cause? Does it need a complete refactoring or some mechanism to harden the whole thing (a bit like VclPtr and derivates)? Perhaps there is some prerequisite janitory task to do?
Let's revamp this tracker since failing pdf conversion must be due to the pb of never ending (at least not in the 30s whereas the files are not big) layout loop.
Created attachment 180556 [details] UNA-AGOSTO.doc Annoying report with multiple files zipped elsewhere with similar names. I add here renamed. No repro for UNA-AGOSTO. Opens and converts to PDF normally.
Created attachment 180557 [details] UNA-CIGA.doc Repro in 4.1 and 7.4+ open problem for UNA-CIGA.doc, high CPU and no response.
Created attachment 180558 [details] UNA-EI.doc Repro in 7.4+ for UNA-EI.doc. But not in 5.4. So all examples are different. This one seems regression in range 6.0-6.4. Since regression is easiest to catch, I think that this bug should focus no this example.
Created attachment 180559 [details] UNA-EI-OFIC.doc
Here is a bibisect in 6.2. Julien please verify. source 7ed962571df02d1d7b286e7af534fadd717a8003 prev 66f633086e2cf0c814df04627bff810d08e73329 author Patrick Jaap <patrick.jaap@tu-dresden.de> 2019-01-23 committer Miklos Vajna <vmiklos@collabora.com> 2019-02-11 tdf#122878: enable wrap for flys in footer This patch removes the check for a footer node, intoduced by 23f698ecee033612ac3a9f5cfd7674b08bb3ccd1 preserving the behaviour for the connected bug reports i13832 and i24135. Without this check, the wraping becomes enabled for footer objects, too. With this enhencement, the commits 7df33caac85ac90c26e97dedbc201f46dc9e4cb4 d3db6ff43a531ecf1afc858a0a8832353d091644 are directly affected and therefore the unit test is edited.
Created attachment 180560 [details] UNA-EI.docx saved in MSO Bibisect was for UNA-EI.doc. And here is UNA-EI.docx saved in MSO.
(In reply to Timur from comment #12) > Here is a bibisect in 6.2. Julien please verify. > > source 7ed962571df02d1d7b286e7af534fadd717a8003 > prev 66f633086e2cf0c814df04627bff810d08e73329 > > author Patrick Jaap <patrick.jaap@tu-dresden.de> 2019-01-23 > committer Miklos Vajna <vmiklos@collabora.com> 2019-02-11 > tdf#122878: enable wrap for flys in footer > This patch removes the check for a footer node, > intoduced by 23f698ecee033612ac3a9f5cfd7674b08bb3ccd1 > preserving the behaviour for the connected bug reports > i13832 and i24135. > > Without this check, the wraping becomes enabled for footer > objects, too. > > With this enhencement, the commits 7df33caac85ac90c26e97dedbc201f46dc9e4cb4 > d3db6ff43a531ecf1afc858a0a8832353d091644 > are directly affected and therefore the unit test is edited. Trying to revert this with: diff --git a/sw/source/core/text/txtfly.cxx b/sw/source/core/text/txtfly.cxx index 88f0687de8c1..d51a686bed4a 100644 --- a/sw/source/core/text/txtfly.cxx +++ b/sw/source/core/text/txtfly.cxx @@ -799,6 +799,7 @@ bool SwTextFly::GetTop( const SwAnchoredObject* _pAnchoredObj, // #i13832#, #i24135# wrap around objects in page header ( !pIDSA->get(DocumentSettingId::USE_FORMER_TEXT_WRAPPING) && nullptr != ( pHeader = pTmp->FindFooterOrHeader() ) && + !pHeader->IsFooterFrame() && m_pCurrFrame->IsInDocBody()))) { if( pHeader || RndStdIds::FLY_AT_FLY == rNewA.GetAnchorId() ) diff --git a/writerfilter/source/dmapper/DomainMapperTableHandler.cxx b/writerfilter/source/dmapper/DomainMapperTableHandler.cxx index d0c42576202e..b4ef84d70cc1 100644 --- a/writerfilter/source/dmapper/DomainMapperTableHandler.cxx +++ b/writerfilter/source/dmapper/DomainMapperTableHandler.cxx @@ -1186,6 +1186,7 @@ void DomainMapperTableHandler::ApplyParagraphPropertiesFromTableStyle(TableParag rParaProp.m_rPropertySet->setPropertyValue( "FillStyle", uno::Any(drawing::FillStyle_SOLID) ); } } + else if (!m_rDMapper_Impl.IsInHeaderFooter()) // FIXME: tdf#116989 floating objects anchored else { // apply style setting only on text portions without direct modification of it it still doesn't work for 149424 UNA-AGOSTO.doc and 149424 UNA-CIGA.doc but seems to work for 149424 UNA-EI.doc At least, it opens and doesn't lag too much when scrolling even if there are these kind of logs: warn:sw.core:42443:42443:sw/source/core/view/vdraw.cxx:246: Trying to move anchor from invalid page - fix layouting! warn:legacy.osl:42443:42443:vcl/source/outdev/bitmap.cxx:249: CopyBits with zero or negative width or height
(In reply to Julien Nabet from comment #14) > Trying to revert this: > it still doesn't work for 149424 UNA-AGOSTO.doc and 149424 UNA-CIGA.doc but > seems to work for 149424 UNA-EI.doc This bug may be layout in general, but also it can be focused on fixable regression for UNA-EI.doc where behavior is the same for UNA-EI.docx. I add Patrick to CC.
A fresh debug build spews this on the console every second or two: warn:legacy.osl:23929:23929:sw/source/core/layout/layact.cxx:755: LoopControl_3 in Interrupt formatting in SwLayAction::InternalAction