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
Writer hangs forever until I manually killed the process
It shouldn't hang
User Profile Reset: Yes
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.
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
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
Regression introduced by:
author Mike Kaganski <email@example.com> 2016-12-08 23:01:03 +0300
committer Miklos Vajna <firstname.lastname@example.org> 2016-12-12 08:23:30 +0000
commit 6f5024de2e1a5cc533527e45b33d9a415467c48d (patch)
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]
*** 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.
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. ***
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: 188.8.131.52.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
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).