Bug 124795 - Scrolling: Writer 100% CPU on specific docx with table structure (see comment 41)
Summary: Scrolling: Writer 100% CPU on specific docx with table structure (see comment...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Scrolling-PageUpDown
  Show dependency treegraph
 
Reported: 2019-04-17 13:19 UTC by kkivi
Modified: 2021-06-18 13:37 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
try open this file (117.48 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-04-17 13:19 UTC, kkivi
Details
screenshot (249.78 KB, image/png)
2019-05-27 16:00 UTC, kkivi
Details
screenshot 100% CPU (347.52 KB, image/png)
2019-05-30 18:14 UTC, kkivi
Details
6.4 version proof (305.73 KB, image/png)
2019-07-03 12:29 UTC, kkivi
Details
seconf example (35.88 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-01-09 21:25 UTC, kkivi
Details
new 3 minutes hang (45.41 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-01-14 21:01 UTC, kkivi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kkivi 2019-04-17 13:19:15 UTC
Created attachment 150823 [details]
try open this file

When opening  attached   hang-final.docx 
LibreOffice Writer 
hangs with 100% CPU. It is possible to scroll to the middle of 
the document and after that nothing can be done.


Version: 6.1.5.2
Build ID: 1:6.1.5-0ubuntu0.18.10.1


Older version opens the same document without problems, more specifically it is 5.1.6.2, 1:516~rc2-0ubuntu1~xenial6
Comment 1 Xisco Faulí 2019-04-17 14:10:49 UTC
Hello,
Thanks for reporting this issue.
This is a duplicate of bug 119253 and it's fixed in LibreOffice 6.2.3

*** This bug has been marked as a duplicate of bug 119253 ***
Comment 2 kkivi 2019-05-24 10:27:34 UTC
I downloaded 6.2.4.2 and it still hangs on this file
Comment 3 Xisco Faulí 2019-05-27 14:57:39 UTC Comment hidden (obsolete)
Comment 4 kkivi 2019-05-27 16:00:17 UTC
Created attachment 151706 [details]
screenshot

same result
Comment 5 kkivi 2019-05-27 16:01:42 UTC Comment hidden (obsolete)
Comment 6 kkivi 2019-05-30 08:54:59 UTC
I have tested 6.2.4.2 Windows version  - same problem
Comment 7 Xisco Faulí 2019-05-30 10:28:10 UTC Comment hidden (obsolete)
Comment 8 kkivi 2019-05-30 12:30:05 UTC Comment hidden (obsolete)
Comment 9 Dieter 2019-05-30 13:10:25 UTC
I can't confirm it with

Version: 6.3.0.0.alpha1+ (x64)
Build ID: e92dcfdc7bd7b237e0bee26ff226a102d9e8e766
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-14_00:00:57
Locale: en-US (de_DE); UI-Language: en-US
Calc: threaded

Takes less than 10 sec to open file.
Comment 10 kkivi 2019-05-30 13:13:50 UTC Comment hidden (obsolete)
Comment 11 Dieter 2019-05-30 16:16:13 UTC
(In reply to kkivi from comment #10)
> Try to scroll it back and force. It will get stuck.
> Watch CPU LOAD at the same time

Using touchpad fro scrolling CPU is around 33% at maximum. It hangs for several seconds. But I can't confirm CPU 100%.
Comment 12 kkivi 2019-05-30 18:14:43 UTC
Created attachment 151789 [details]
screenshot 100% CPU

This is 100% CPU screenshot from Linux.
We use different operating systems, so there may be a difference in details.

I cannot work with this (short) file. Can you?
Comment 13 kkivi 2019-07-02 14:52:19 UTC
I feel I must add, that I do not agree with the renaming this bug.
Under Linux, it is an absolute disaster, it barely manages to load the first page
Comment 14 Xisco Faulí 2019-07-02 14:55:07 UTC Comment hidden (obsolete)
Comment 15 kkivi 2019-07-03 12:28:45 UTC
6.4 alpha still runs at 100% CPU when I move down below 
page 25
Comment 16 kkivi 2019-07-03 12:29:36 UTC
Created attachment 152530 [details]
6.4 version proof
Comment 17 kkivi 2019-07-03 12:43:06 UTC
I believe that this could not be fixed by general performance improvements.
I think the table parsing algorithm should be revised.

As I said, version 5.1.6.2 opens this file without any problem
Comment 18 QA Administrators 2019-07-04 02:47:59 UTC Comment hidden (obsolete)
Comment 19 mattia.b89 2019-09-07 18:56:40 UTC Comment hidden (delete, obsolete)
Comment 20 mattia.b89 2019-09-07 19:01:20 UTC
(In reply to mattia.b89 from comment #19)
> I am not able to reproduce the issue
> 
> Version: 6.3.1.2
> Build ID: 6.3.1-1
> CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3; 
> Locale: it-IT (en_GB.UTF-8); UI-Language: en-GB
> Calc: threaded

NO, I have this issue too!
Comment 21 Xisco Faulí 2019-09-26 08:05:35 UTC Comment hidden (obsolete)
Comment 22 Xisco Faulí 2019-09-26 08:07:00 UTC
OTOH, not reproducible in

Version: 5.2.0.0.alpha1+
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8)
Comment 23 Xisco Faulí 2019-09-26 08:19:12 UTC
Also reproducible in

Version: 5.4.0.0.alpha1+
Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 24 kkivi 2019-12-16 13:01:17 UTC
I reproduced this bug on a new computer with 32GB of RAM.
soffice.bin consumes 12GB ( on a file that was easily handled by version 5)

Is there any hope, that this issue will be addressed?
Comment 25 Xisco Faulí 2019-12-27 16:50:00 UTC
(In reply to Xisco Faulí from comment #21)
> I do confirm it in
> 
> Version: 6.4.0.0.alpha0+
> Build ID: 186d36a7036462ae641b35004b4ffba3eeeca46f
> 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
> 
> it hangs  in page 17/18 using page av key

No longer reproducible in

Version: 6.5.0.0.alpha0+
Build ID: 1abfc8e2f677024ea058e96f3133e503ba89ea02
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

Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
Comment 26 Telesto 2020-01-03 19:47:00 UTC
No repro with
Version: 6.5.0.0.alpha0+ (x64)
Build ID: 42a1a1c6b91907f81e15066ffab219411f18c4db
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: GL; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 27 Dieter 2020-01-05 16:38:58 UTC Comment hidden (obsolete)
Comment 28 Xisco Faulí 2020-01-07 13:13:27 UTC
two people couldn't reproduce it in master. I think we can already close it as RESOLVED WORKSFORME
Comment 29 Xisco Faulí 2020-01-07 16:55:23 UTC
Also fixed in

Version: 6.4.0.1.0+
Build ID: 956231069ef97113fc398dd61804fde0101ea746
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 30 Xisco Faulí 2020-01-07 17:43:01 UTC Comment hidden (obsolete)
Comment 31 László Németh 2020-01-07 22:04:22 UTC Comment hidden (obsolete)
Comment 32 Xisco Faulí 2020-01-08 09:06:20 UTC
(In reply to László Németh from comment #31)
> (In reply to Xisco Faulí from comment #30)
> > The issue got fixed by
> > https://cgit.freedesktop.org/libreoffice/core/commit/
> > ?id=2c918aa51e5528b090e52fa31b10fa17cf2593ae
> > 
> > @László, thanks for fixing this issue!
> 
> @Xisco: That's not a general fix for DOCX layout dead locks, but document
> handling is more like a little like MSO does, so I hope, too, there will be
> fewer problems... Thanks!

Yep, I was a bit surprise of the result too. Probably other changes helped as well, but your commit definitely helped as well. Thanks!
Comment 33 kkivi 2020-01-09 21:03:56 UTC
I can confirm that development version 6.5 opens the example document without a problem. Unfortunately, there is still an issue ( though less severe - 100% CPU and hangs for about a minute during repagination in the middle of the document ) with the original document. I cannot post it here, but I will try to amend it to demonstrate the problem.
Comment 34 kkivi 2020-01-09 21:25:04 UTC
Created attachment 157047 [details]
seconf example

version 6.5 hangs for a minute on the original document ( with Warning message "application doesn't respond"). However, things are much better - after the initial load I can finally scroll and edit freely. I can also save it in odt format which has no further problems. 
I attached an amended document, which freezes shortly when scrolled to page 27-28 for the first time.

What status should be set on this bug, given this new information?
Comment 35 kkivi 2020-01-14 21:01:09 UTC
Created attachment 157151 [details]
new 3 minutes hang

This version causes 6.5 to hang at page 20 for at least 3 minutes with 
gnome message box stating that  "application not responding"
Comment 36 kkivi 2020-01-30 07:58:42 UTC Comment hidden (obsolete)
Comment 37 Buovjaga 2020-06-07 19:32:53 UTC
(In reply to kkivi from comment #35)
> Created attachment 157151 [details]
> new 3 minutes hang
> 
> This version causes 6.5 to hang at page 20 for at least 3 minutes with 
> gnome message box stating that  "application not responding"

I bibisected with win32-5.3 repo to https://git.libreoffice.org/core/+/8a800eea613c0f5ad3302136766791dc58880fb3%5E!/
tdf#104425 sw: split rows w/large min height (fix layout loop)

Adding Cc: to Mike Kaganski
Comment 38 mattia.b89 2020-06-07 19:50:57 UTC Comment hidden (obsolete)
Comment 39 Buovjaga 2020-06-08 06:27:32 UTC Comment hidden (obsolete)
Comment 40 mattia.b89 2020-06-08 14:59:28 UTC
(In reply to Buovjaga from comment #39)
> (In reply to mattia.b89 from comment #38)
> > issue seems gone for me (tried with file attached here)
> > 
> > Arch Linux w/ libreoffice-fresh 6.4.4-1
> 
> It's not gone, if you try with attachment 157151 [details]
> 
> Arch Linux 64-bit
> Version: 7.1.0.0.alpha0+
> Build ID: 2bccbd2ba6c90d5e02285629c2b079c35260c08b
> CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3
> Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> Calc: threaded
> Built on 3 June 2020

correction: with that file LO hangs
Comment 41 Telesto 2020-11-17 19:07:10 UTC
Situation has improved, only attachment 3, so attachment 157151 [details] still slow
Version: 7.1.0.0.alpha1+ (x64)
Build ID: 312a33b7636334f6ce3b6d1702bc5d3e45215601
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
Comment 42 Timur 2021-06-10 10:08:15 UTC
This bug should've been closed when original issue of attachment 150823 [details]  was resolved. It's wrong to add more different examples.

3rd sample DOCX attachment 157151 [details] is LO created, which is also wrong (acceptable is ODT saving and reopening as DOC/X but we don't have ODT). I had MSO crash on open and again on save. 
Still I could normally scroll all 60 pages in LO 7.2+ without special hang, just somewhat higher CPU. Note that immediate and relentless holding of PageDown can crash it, but this is long table and tables in Writer are anyway not CPU efficient. 
I see high CPU with 5.3 oldest so I don't see how that one is regression.
So I close this.
Comment 43 Timur 2021-06-10 10:13:32 UTC
Similar but more clear is Bug 125171.
Comment 44 kkivi 2021-06-10 10:44:19 UTC
(In reply to Timur from comment #42)
> This bug should've been closed when original issue of attachment 150823 [details]
> [details]  was resolved. It's wrong to add more different examples.
> 
> 3rd sample DOCX attachment 157151 [details] is LO created, which is also
> wrong (acceptable is ODT saving and reopening as DOC/X but we don't have
> ODT). I had MSO crash on open and again on save. 
> Still I could normally scroll all 60 pages in LO 7.2+ without special hang,
> just somewhat higher CPU. Note that immediate and relentless holding of
> PageDown can crash it, but this is long table and tables in Writer are
> anyway not CPU efficient. 
> I see high CPU with 5.3 oldest so I don't see how that one is regression.
> So I close this.

I would like to note the last example is just a more accurate representation of the original example, that I could not include for the obvious reason.
The document has the same structure better resembles the original in regard to word boundaries.

I object to closing this bug
Comment 45 Timur 2021-06-18 13:37:01 UTC
Original issue is not reproducible. Another issue should be elsewhere.
Seems that problem is in saving in LO, because 3rd sample DOCX attachment 157151 [details] is LO created and attachment 172773 [details] in bug 142773 was created from this bug 124795 (just anonymized table from attachment 150823 [details]).
So let's continue there.