Bug 85886 - VIEWING: A Navigator entry in particular .odt pegs CPU
Summary: VIEWING: A Navigator entry in particular .odt pegs CPU
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Michael Stahl (allotropia)
Whiteboard: target:4.4.0 target:4.4.0
Keywords: bibisected, perf, regression
Depends on:
Reported: 2014-11-05 02:30 UTC by Terrence Enger
Modified: 2015-12-15 11:08 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Terrence Enger 2014-11-05 02:30:24 UTC
My adventure with this bug started with an attempt to reproduce
bug 85861.  This one is different in that:
(*) My problem is high CPU usage instead of a crash.
(*) My problem happens earlier in the STR.

STR, using daily dbgutil bibisect repository version 2014-11-04:

(0) Download the .odt file attached to bug 85861

(1) Optionally, run System Monitor, or `top`, or something to show you
    CPU usage.

(2) Open the .odt from the command line.  Program displays page 1
    of 91.  Observe heading "1.11 COORDENADA" about 1/3 of the way
    down the page.

(3) If the Navigator window is not open, type <F5>.  The list area of
    the navigator window blinks briefly about once per second.

(4) In the Navigator window, expand Headings > "PARTE I: LAS LEYES
    HATURALES" > 1.1 and then double click "1.11 COORDENADAS".

    (a) In the document area, the cursor moves to start of heading
        "1.11 COORDENADAS".

    (b) In the Navigator window, line "1.11 COORDENADAS" is
        highlighted and it moves to the top of the list area.

    (c) About once per second for half a minute or so, the list area
        is blanked briefly or the scrollbars are blanked briefly.

    (d) Gradually the CPU usage increases to 100%.  I have let the
        program run this way for as long as a few minutes.

(5) Type <Alt>+F <Alt>+X.  Program exits, as commanded.

Working in the daily dbgutil bibisect repository, I ignored
differences in the quality of the blinking Navigator window,
uncommanded collapse or not of the list after the double click in Step
(4), and repositioning (or not) of the list after the double-click.
In short, I called the loop "bad" and anything else "good".  Most
importantly, I ran each version of LibreOffice with its own user
profile.  The result, in short:

    version      commit    s-h       behaviour
    ----------   -------   -------   --------
    2014-05-23   aa51564   c68c5e7   no loop
    2014-05-24   20faa9b   474f484   loop

However, if I then run version 2014-05-23 with user profile previously
created by 2014-05-24, the program again loops.

For comparison, I see no loop in version:

    Build ID: 768d22a83e7e6aae430b2e5e4ed28f2574aad12d
    TinderBox: Win-x86@39, Branch:master, Time: 2014-11-04_09:19:00

In the interval c68c5e7..474f484 I see 181 commits.  My naive
attention goes to:

    commit 6eaad9e41ae95a3d973e72439ef580349e3e8e4b
    Author: Ulrich Kitzinger <ulkitz@hotmail.de>
    Date:   Fri May 23 09:10:57 2014 +0200

        Resolves: fdo#58187 Expand and Collapse should be virtual
        regression from ac7acb0ab1329913b0cec79790adcde0263960be

Comparing the two user profile directories as they were after the
first execution of the particular versions of LibreOffice, I see that
user/registrymodifications.xcu for version 2014-05-24 (the version
which looped) has extra lines 3 through 9, to which I add whitespace
for readability:

    <item oor:path="/org.openoffice.Office.Writer/Navigator">
      <prop oor:name="ShowListBox" oor:op="fuse">
    <item oor:path="/org.openoffice.Office.Writer/Navigator">
      <prop oor:name="SelectedPosition" oor:op="fuse">
    <item oor:path="/org.openoffice.Office.Writer/Navigator">
      <prop oor:name="RootType" oor:op="fuse">
    <item oor:path="/org.openoffice.Office.Writer/Navigator">
      <prop oor:name="InsertMode" oor:op="fuse">
    <item oor:path="/org.openoffice.Office.Writer/Navigator">
      <prop oor:name="OutlineLevel" oor:op="fuse">
    <item oor:path="/org.openoffice.Office.Writer/Navigator">
      <prop oor:name="GlobalDocMode" oor:op="fuse">
    <item oor:path="/org.openoffice.Office.Writer/Navigator">
      <prop oor:name="ActiveBlock" oor:op="fuse">

Comment 1 Julien Nabet 2014-11-11 10:53:03 UTC
On pc Debian x86-64 with master sources updated yesterday, I reproduced this partly.

I mean, I reproduced:
but not 4)d) the cpu increases but then decreases.

Anyway the cpu consumption is quite weird, so putting at NEW.
Comment 2 Commit Notification 2014-11-21 16:39:20 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":


fdo#85886 don't redraw the Navigator content tree if nothing changed

It will be available in 4.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Comment 3 Michael Stahl (allotropia) 2014-11-21 20:48:53 UTC
i've noticed 2 problems here:

1. when the navigator is displayed a timer fires once a second
   and fetches the entire content from the document and re-draws;
   this is a "regression" in so far as before commit
   6eaad9e41ae95a3d973e72439ef580349e3e8e4b the navigator was
   pretty much broken...

2. the layout is not stable; on the last page there is an
   osciallation where a paragraph and some fly invalidate
   each other forever eating up 10-15% of a (pretty fast)
   CPU with --enable-dbgutil (no optimizations);
   this can be reproduced in current libreoffice-4-3, 4.2.6
   and 3.5.7 too which is the earliest version for which
   i've got a dbgutil build with the green/red pixel...

of course the 2nd problem is independent from having the navigator

i've pushed a patch that may help with the 1st problem;
if you get a high CPU load without the navigator open
it's probably 2nd problem which doesn't look like a regression
and should be a separate bug;
if you still see very high CPU load only with navigator open
please re-open this bug.
Comment 4 Terrence Enger 2014-11-22 17:02:54 UTC
Thank you, Michael.  Good work.  More specifically ...

W.r.t. problem 1:

(*) In daily dbgutil bibisect repository version 2014-11-22, which now
    embeds the Navigator into the Sidebar, I see no flashing of the
    navigator, and with the sidebar open LibreOffice is using about 3%
    of my CPU.

    This is a clear improvement from the version of 2014-11-21, where
    the flashing was conspicuous and CPU usage with the navigator open
    was about 25%.

(*) In Widows TinderBox from 2014-11-21_23:15:55, with the Navigator
    open, I see no flashing and the CPU usage is nil.

    This is an improvement over TinderBox from 2014-11-21_00:01:14,
    where the Navigator flashes conspicuously and the program used 20%
    of the CPU, reducing later to 3 to 5 percent.

W.r.t. problem 2:

I have not seen this problem at all.  I see no visible redrawing of
the last page, and without Navigator, the CPU usage in the later
version on Linux eventually settles down to 1 to 3 percent.

I think I should not file the bug report for this one.

Comment 5 Terrence Enger 2014-11-22 17:03:44 UTC

About the fact that your CPU usage dropped back instead of staying
pegged as in my step (4)(d):

I think this is plausibly explained by the timer that Michael
mentioned in comment 3 and the assumption that your CPU is faster than
mine.  I could play around to test this assumption, but I shall do
that only if you can see some value in it.

Comment 6 Michael Stahl (allotropia) 2014-11-24 20:45:15 UTC
libreoffice-4-4 commit is b5c1f352522c34a744ad0226e73904ce5af81b11
Comment 7 Gordo 2015-03-18 16:46:23 UTC
Reopened because still seeing constant cpu usage with the Navigator opened.

Using this document as an example:  https://wiki.documentfoundation.org/images/2/2f/WG42-WriterGuideLO.odt

With the Navigator open I am seeing a constant 15% cpu usage and scrolling through the document is slow.  If the Navigator is closed or has focus, the cpu drops down.

This is in the Win version.

Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Comment 8 Robinson Tryon (qubit) 2015-03-31 15:47:59 UTC
(In reply to Gordo from comment #7)
> Reopened because still seeing constant cpu usage with the Navigator opened.

Hi Gordo,
Sounds like this bug does not meet the criteria for Status 'REOPENED'
Status back to -> VERIFIED FIXED

Please file a new bug regarding your Navigator problems, and we can triage that issue separately. Thanks!
Comment 9 Robinson Tryon (qubit) 2015-12-15 11:08:17 UTC Comment hidden (obsolete)