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: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: high major
Assignee: Not Assigned
Keywords: bibisected, bisected, perf, regression
: 114968 121976 126704 132198 138026 142773 (view as bug list)
Depends on:
Blocks: Writer-Table-Layouting
  Show dependency treegraph
Reported: 2018-11-26 14:12 UTC by Franklin Weng
Modified: 2021-07-28 09:59 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:

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

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
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

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

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

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:


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.
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
*** Bug 138026 has been marked as a duplicate of this bug. ***
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: (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).