Bug 121720 - [TABLE] A merged table cell across page (due to other columns containing multiple rows) would cause Writer hang forever
Summary: [TABLE] A merged table cell across page (due to other columns containing mult...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.7.2 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf, regression
: 132198 (view as bug list)
Depends on:
Blocks: Writer-Table-Layouting
  Show dependency treegraph
 
Reported: 2018-11-26 14:12 UTC by Franklin Weng
Modified: 2024-06-11 12:29 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
Problematic odt file (67.72 KB, application/vnd.oasis.opendocument.text)
2018-11-26 14:13 UTC, Franklin Weng
Details
perf flamegraph (1.70 MB, image/svg+xml)
2019-08-05 21:41 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Franklin Weng 2018-11-26 14:12:14 UTC
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.
Comment 1 Franklin Weng 2018-11-26 14:13:47 UTC
Created attachment 147052 [details]
Problematic odt file

The file was converted from doc to odf.  Built by Word 2003 originally.
Comment 2 Xisco Faulí 2018-11-26 15:23:57 UTC
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
Comment 3 Xisco Faulí 2018-11-26 15:35:21 UTC
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
Comment 4 Mike Kaganski 2018-11-26 19:58:37 UTC Comment hidden (obsolete)
Comment 5 Franklin Weng 2018-11-26 21:30:23 UTC
(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.
Comment 6 Xisco Faulí 2019-08-05 11:20:24 UTC
*** Bug 126704 has been marked as a duplicate of this bug. ***
Comment 7 Xisco Faulí 2019-08-05 11:21:34 UTC Comment hidden (obsolete)
Comment 8 Julien Nabet 2019-08-05 21:41:55 UTC
Created attachment 153148 [details]
perf flamegraph
Comment 9 Telesto 2019-12-27 17:22:52 UTC
*** Bug 121976 has been marked as a duplicate of this bug. ***
Comment 10 Telesto 2019-12-27 17:24:25 UTC
*** Bug 114968 has been marked as a duplicate of this bug. ***
Comment 11 Justin L 2020-05-02 17:12:14 UTC
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?
Comment 12 Telesto 2020-05-02 18:57:38 UTC
(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
Comment 13 mattia.b89 2020-06-07 19:52:09 UTC
issue seems gone for me (tried with file attached here)

Arch Linux w/ libreoffice-fresh 6.4.4-1
Comment 14 Telesto 2020-11-06 22:10:52 UTC Comment hidden (obsolete)
Comment 15 Justin L 2021-03-17 05:53:50 UTC
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.
Comment 16 Telesto 2021-06-18 14:16:49 UTC
*** Bug 142773 has been marked as a duplicate of this bug. ***
Comment 17 Telesto 2021-06-18 14:18:40 UTC
*** Bug 132198 has been marked as a duplicate of this bug. ***
Comment 18 Telesto 2021-07-22 08:24:52 UTC
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
Comment 19 Justin L 2021-07-26 05:59:58 UTC
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).
Comment 20 Buovjaga 2022-04-13 16:53:13 UTC
(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
Comment 21 Aron Budea 2022-04-13 21:34:45 UTC
(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.
Comment 22 Justin L 2023-05-12 00:14:50 UTC
Still laggy in 7.6+, but didn't seem as bad. My CPU wasn't maxed out too much this time.
Comment 23 Xisco Faulí 2023-06-02 10:04:32 UTC
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 ?
Comment 24 Julien Nabet 2023-06-03 07:05:21 UTC
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.
Comment 25 Julien Nabet 2023-06-03 07:09:01 UTC
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
Comment 26 Timur 2023-10-10 19:02:38 UTC
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..
Comment 27 Timur 2023-10-10 19:13:44 UTC
In 7.5 opening seemed faster. But results are not consistent for a bisect.
Comment 28 Timur 2023-10-11 08:40:16 UTC
Reports that were duplicates here:
Bug 142773, bug 138026 (opened)
Bug 121976, bug 114968, bug 126704, bug 144240 (fixed).