Bug 99800 - Long compute loops when opening and modifying an odt file
Summary: Long compute loops when opening and modifying an odt file
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, perf
Depends on:
Blocks: CPU-AT-100% Writer-Table-Layouting
  Show dependency treegraph
 
Reported: 2016-05-12 16:11 UTC by Nicolas Mailhot
Modified: 2020-04-19 19:27 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
testcase (758.84 KB, application/vnd.oasis.opendocument.text)
2016-05-12 16:11 UTC, Nicolas Mailhot
Details
Callgrind with 5.2 (8.59 MB, application/x-xz)
2016-05-16 10:48 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Mailhot 2016-05-12 16:11:40 UTC
Created attachment 125010 [details]
testcase

Writer mismanages the attached odt testcase, is lost into long compute loops at document opening and when modifying the document content
Comment 1 Nicolas Mailhot 2016-05-12 20:08:24 UTC
The document does load (on win32 & underpowered Fedora x86-64 chromebook), it's just pathologically long. It seems writer has lots of problems computing page and column breaks in this document. I did gave up on document loading several times, killing writer and restarting it on the same document usually succeeded (after a looong time).

The issue seems to be inherited from openoffice.org.
Comment 2 Nicolas Mailhot 2016-05-15 16:23:54 UTC
Confirmed in

https://bugs.documentfoundation.org/show_bug.cgi?id=99803#c1

Since bug #99803 uses the same testcase for another problem
Comment 3 Buovjaga 2016-05-16 10:48:13 UTC
Created attachment 125080 [details]
Callgrind with 5.2

Took a callgrind of opening the document fully.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.2.0.0.alpha1+
Build ID: 1dbdc947fcc9d843764731e6dae7ce60082576e0
CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8)
Built on May 14th 2016
Comment 4 Nicolas Mailhot 2016-09-10 11:04:53 UTC
After further testing on the actual document that served as basis for the testcase, the loops seem to be linked to the "balance column contents" enabled in some sections.

Unchecking this option removes (so far, crossing fingers) the pathologic slowdowns on my test system (5.2.1, win x86_64)

So it's probably a broken balancing algorithm.
Comment 5 Xisco Faulí 2017-09-29 08:53:10 UTC Comment hidden (obsolete)
Comment 6 Michael Warner 2019-05-14 03:50:41 UTC
I just tested it with 5.1.6.2. I didn't have any trouble opening the document, but multiple times it would freeze my entire windowing system when I tried to scroll through page 16. I couldn't get other windows to respond, even. My CPU usage seemed fine though. I think the particular issue described here may be fixed but it's exposing another issue.
Comment 7 Michael Warner 2019-05-14 03:52:18 UTC
Modifying the document doesn't seem to trigger any issues.
Comment 8 Michael Warner 2019-05-14 03:54:07 UTC
Perhaps I spoke too soon. When reloading the document after editing, it did freeze up for a long time.
Comment 9 Michael Warner 2019-05-14 03:55:37 UTC
I'm using Linux Mint 18.1 by the way.
Comment 10 Michael Warner 2019-05-14 04:05:03 UTC
I tried using a build of the trunk that I checked out yesterday. Initial load was fine, but when I used File->Reload it was very slow to open. I see a million of these warnings in my console:

    warn:legacy.osl:7671:7671:sw/source/core/layout/tabfrm.cxx:2635: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910
    warn:legacy.osl:7671:7671:sw/source/core/layout/wsfrm.cxx:1501: Negative reduction?
    warn:legacy.osl:7671:7671:sw/source/core/layout/wsfrm.cxx:2764: nDist < 0
    warn:legacy.osl:7671:7671:sw/source/core/layout/tabfrm.cxx:2635: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910
    warn:legacy.osl:7671:7671:sw/source/core/layout/tabfrm.cxx:2635: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910
    warn:legacy.osl:7671:7671:sw/source/core/layout/tabfrm.cxx:2635: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910
    warn:legacy.osl:7671:7671:sw/source/core/layout/tabfrm.cxx:2635: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910
    warn:legacy.osl:7671:7671:sw/source/core/layout/tabfrm.cxx:2635: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910
Comment 11 Buovjaga 2019-05-14 07:36:27 UTC
(In reply to Michael Warner from comment #10)
> I tried using a build of the trunk that I checked out yesterday. Initial
> load was fine, but when I used File->Reload it was very slow to open. I see
> a million of these warnings in my console:
> 
>     warn:legacy.osl:7671:7671:sw/source/core/layout/tabfrm.cxx:2635: debug
> assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by
> fix i44910

Ah, are you using a build ending with -dbg? Those unfortunately mess with the performance.

I'm getting the same load time with reload with a non-debug build. Yet, there is something pathological about the document. Like you say in comment 6, if we scroll the document past half way, it freezes the whole system for a while.

Bug 99803 is at least solved, the replace completes in 6 seconds for me.

I guess I should open a new report for the scrolling freeze.

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 038e4b3b1e10d072b432cb06234521ae9a262a70
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 12 May 2019