Download it now!
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)
Version:
(earliest affected)
5.2.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf, regression
: 114968 121976 126704 (view as bug list)
Depends on:
Blocks: Writer-Tables 132261
  Show dependency treegraph
 
Reported: 2018-11-26 14:12 UTC by Franklin Weng
Modified: 2020-05-02 18:57 UTC (History)
8 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
(In reply to Xisco Faulí from comment #3)

Hmm... but OP told that 5.2 already hangs?
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
@Julien, Could it be possible to have a perf graph here ?
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