Description: 1. The file was converted from doc to odt. 2. There are tables with multiple columns which made the cell width narrow 3. A cell (in the attached file the leftest column) is across the page due to other columns containing multiple rows, the part in the top of the second page wouldn't be able to edit, and couldn't be clicked showing that the cell was locked and couldn't be edited 4. Opening such files in LibreOffice 5.2+ would cause Writer hang forever with CPU rate 100+% 5. However in LibreOffice 4.0 when clicking such a cell the cursor can go there, just can't edit, and doesn't hang either Steps to Reproduce: 1. Open the attached file in LibreOffice 5.2+ Writer (also reproducible in 6.1.2) 2. Writer would very easily hang after some actions 3. Actual Results: Writer hangs forever until I manually killed the process Expected Results: It shouldn't hang Reproducible: Always User Profile Reset: Yes Additional Info: In LibreOffice 4.0 it worked well opening/editing the file. When clicking the crossed cell the cursor could go to the second part (in the top of the second page) just couldn't edit. In 5.2+ the cursor couldn't go there, and it hangs every time.
Created attachment 147052 [details] Problematic odt file The file was converted from doc to odf. Built by Word 2003 originally.
Reproduced in Version: 6.2.0.0.beta1+ Build ID: a63cd8bbe7cf881daa8dc7a7f32f3e5ac384e902 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded but not in Version: 5.3.0.0.alpha1+ Build ID: 4136757b4e51c4e6f7cb4132c95538a7f831ef2c CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; VCL: gtk3; Layout Engine: new; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=6f5024de2e1a5cc533527e45b33d9a415467c48d author Mike Kaganski <mike.kaganski@collabora.com> 2016-12-08 23:01:03 +0300 committer Miklos Vajna <vmiklos@collabora.co.uk> 2016-12-12 08:23:30 +0000 commit 6f5024de2e1a5cc533527e45b33d9a415467c48d (patch) tree de8f7248a9f0361e23dcbb1eacb72f67071d51a9 parent 7740e945e0c74d057c424cced079adc766cc5604 (diff) tdf#104425 sw: split rows w/large min height (fix layout loop) Bisected with: bibisect-linux-64-5.4 Adding Cc: to Mike Kaganski
(In reply to Xisco Faulí from comment #3) Hmm... but OP told that 5.2 already hangs?
(In reply to Mike Kaganski from comment #4) > (In reply to Xisco Faulí from comment #3) > > Hmm... but OP told that 5.2 already hangs? A customized 5.2.7 (for Taiwan gov) has this problem. BTW not sure if your patch was back ported or not.
*** Bug 126704 has been marked as a duplicate of this bug. ***
@Julien, Could it be possible to have a perf graph here ?
Created attachment 153148 [details] perf flamegraph
*** Bug 121976 has been marked as a duplicate of this bug. ***
*** Bug 114968 has been marked as a duplicate of this bug. ***
This document is about 20 pages long with 3 separate tables. When opening, it seems like the layout never becomes stable, since it is constantly looping through layout functions. I tried to reduce the document, but still keep the problem by -deleting each table individually -reducing the number of columns -reducing the number of rows in each table However, while every reduction in complexity seemed to help, nothing seemed to actually fix the problem. In other words, I couldn't pinpoint something specific, but it seems like the more complexity, the more lag or the harder to reach a stable layout. Even when the layout was stable, it was painfully slow to move up and down in the document. I also tried (very unscientifically and randomly) to undo parts of Mike's patch, but didn't find anything in it that seemed to be the cause of the hang. Perhaps it was always laggy and just requires even more calculations now?
(In reply to Justin L from comment #11) > just requires even more calculations now? Probably. M. Stahl has done quite a number commits related to table crashes I reported. It's pretty stable now days (except for aSwFrame::IsLeaveUpperAllowed crash, you can get with bad luck). However, it got a little worse in this area; finding a layout; some kind of infinite loop? This a nice example (except it fixed after copy paste) Instead of me trying to generate some artificial bug doc showing the issue (added a few reports in see also). - There a cases where table rendering stops; with tables going off page. - Table rendering is 'unstable'. Click inside a table, and whole table splitting while change. - Tables splitting, but on every load/versions differently (a document can have 500 or 530 pages.. depending how tables are split; mostly lot of pages + quite number of footnotes, heading etc. - This table of if issue; infinite loop :-) - Table who actually finish after spending quite some time doing shrinking, FindRowFrame (as seen in the basic Very Sleepy profile) All happening with complex documents. Table cross pages, merged cells, footnotes, embedded tables. Especially combining everything, footnotes in embedded (merged) tables. _CxxUnregisterExceptionObject _RTDynamicCast SwFrame::FindRowFrame SwFrame::UnionFrame SwFrame::IsLeaveUpperAllowed SwFrame::Shrink SwLayoutFrame::ShrinkFrame SwFrame::Shrink SwFrame::UnionFrame SwLayoutFrame::MakeAll SwFrame::PrepareMake SwFrame::IsLeaveUpperAllowed SwFrame::IsLeaveUpperAllowed SwFrame::IsLeaveUpperAllowed SwFrame::IsLeaveUpperAllowed SwFrame::PrepareMake SwViewShell::EnableSmooth SwViewShell::EnableSmooth SwViewShell::EnableSmooth SwTextFrame::HasRepaint SwLayoutFrame::MoveLowerFootnotes SwViewShell::LayoutIdle SwBreakIt::GetForbidden Scheduler::ProcessTaskScheduling create_SalInstance
issue seems gone for me (tried with file attached here) Arch Linux w/ libreoffice-fresh 6.4.4-1
*** Bug 138026 has been marked as a duplicate of this bug. ***
repro 7.2+ The document opens so you can see the first page, then the CPU runs at 100% trying to layout the document - and the UI is unresponsive.
*** Bug 142773 has been marked as a duplicate of this bug. ***
*** Bug 132198 has been marked as a duplicate of this bug. ***
Looking pretty OK to me with Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 3d18cae102e16b85fb8787f5ec3b086bfa2bd7b8 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL Note didn't check all the Duplicates
While isn't isn't a "hang forever" in yesterday's 7.3 dev, it still does claim the keyboard/mouse and keep one thread at 100% for a couple of minutes before finishing the page refresh. Then it repeats again when moving to another spot. So still unusable for me (Ubuntu 20.04).
(In reply to Justin L from comment #19) > While isn't isn't a "hang forever" in yesterday's 7.3 dev, it still does > claim the keyboard/mouse and keep one thread at 100% for a couple of minutes > before finishing the page refresh. Then it repeats again when moving to > another spot. So still unusable for me (Ubuntu 20.04). I see nothing like this with a non-debug build. Can everyone please re-test? Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2f2df626117380427d2e5e8417316f52823f1e6f CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
(In reply to Buovjaga from comment #20) > I see nothing like this with a non-debug build. Can everyone please re-test? I do get a hang after a bunch of newlines here and there, with LO 7.4.0.0.alpha0+ (53fe4a26c7c4691fcf9d07d022adfd45247d176b) / Ubuntu.
Still laggy in 7.6+, but didn't seem as bad. My CPU wasn't maxed out too much this time.
No longer reproducible in Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 845054aa25b7cba1daa1ff30b142d549027299bd CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded Could someone else confirm it ?
On pc Debian x86-64 with master sources updated today, it's not very fast when scrolling but I got no hang. If useful I can provide a new Flamegraph.
If it can help, I had these logs on console: warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2237: nDist > than current size. warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:1518: Negative growth? warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:1562: Negative reduction? warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2235: nDist < 0 warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2237: nDist > than current size. warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2237: nDist > than current size. warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:286: SwTextFrame::CalcFollow: cheesy follow warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:291: SwTextFrame::CalcFollow: very cheesy follow warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2237: nDist > than current size. warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:1562: Negative reduction? warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2850: nDist < 0 warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:286: SwTextFrame::CalcFollow: cheesy follow warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:291: SwTextFrame::CalcFollow: very cheesy follow warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2237: nDist > than current size. warn:vcl.gdi:7425:7425:vcl/source/outdev/font.cxx:1083: Font fallback to the same font, but has missing codes warn:vcl.gdi:7425:7425:vcl/source/outdev/font.cxx:1083: Font fallback to the same font, but has missing codes warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:1518: Negative growth? warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:286: SwTextFrame::CalcFollow: cheesy follow warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:291: SwTextFrame::CalcFollow: very cheesy follow warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2237: nDist > than current size. warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:1562: Negative reduction? warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2850: nDist < 0 warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:286: SwTextFrame::CalcFollow: cheesy follow warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:291: SwTextFrame::CalcFollow: very cheesy follow warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2237: nDist > than current size. warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:286: SwTextFrame::CalcFollow: cheesy follow warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:291: SwTextFrame::CalcFollow: very cheesy follow warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2237: nDist > than current size. warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:1562: Negative reduction? warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2850: nDist < 0 warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:286: SwTextFrame::CalcFollow: cheesy follow warn:legacy.osl:7425:7425:sw/source/core/text/frmform.cxx:291: SwTextFrame::CalcFollow: very cheesy follow warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2237: nDist > than current size. warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:1562: Negative reduction? warn:legacy.osl:7425:7425:sw/source/core/layout/wsfrm.cxx:2850: nDist < 0 warn:legacy.osl:7425:7425:sw/source/core/layout/flowfrm.cxx:2632: <SwFlowFrame::MoveBwd(..)> - layout loop control for layout action <Move Backward> applied! warn:legacy.osl:7425:7425:sw/source/core/access/accmap.cxx:2519: frame is not accessible warn:legacy.osl:7425:7425:sw/source/core/access/accmap.cxx:2519: frame is not accessible warn:vcl.gdi:7425:7425:vcl/source/outdev/font.cxx:1083: Font fallback to the same font, but has missing codes warn:vcl.gdi:7425:7425:vcl/source/outdev/font.cxx:1083: Font fallback to the same font, but has missing codes
This bug seems to have become a dumpster for different duplicates. Some seems fixed to me, I closed them. If not fixed, New. One remained that may be a dupe of some other. And this one is no more "hang forever" so I close. There is some CPU but that is another issue, after searching for many similar bugs..
In 7.5 opening seemed faster. But results are not consistent for a bisect.
Reports that were duplicates here: Bug 142773, bug 138026 (opened) Bug 121976, bug 114968, bug 126704, bug 144240 (fixed).