$ top, tap '1', tap 't' twice
$ watch sensors or $ watch inxi -s
$ watch free -m
$ watch df -h /dev/sdax

Synopsis:

The ODT load on a 600 page document has become so high as to freeze LibreOffice and, on a couple of occasions, also freeze Devuan solid.

$ lscpu | fgrep 'Model name'
Model name:                           AMD A8-7410 APU with AMD Radeon R5 Graphics

Work is in process to reduce that load.

The following has been completed:

1. All Direct Paragraph Style have been changed for other styles (mostly Text Body)
   [note: in 24.8 “Text Body” has been renamed to “Body Text”]

2. Each Heading x style (levels 1, 2, 3 + 4) contains a Text-Box (TB) at the far-right as an extra visual clue. Each TB has been swapped out for a Frame
   [styles: H1Frame, H2Frame, H3Frame + H4Frame]

The following is still in process:

• DrawObjects are being swapped out for PNG images

• Several hundred Direct Formats with a FreeMono font are being swapped out with a self-created “Console” Character Style
  [the original PDF described this style as “Lightface”]

Bug-Traces

Just like slugs, Bugs leave sure-fire notice of their existence.

1. On document load the page count (Status Bar at bottom left) would vary wildly from moment-to-moment

2. The DrawObjects would move location, often across pages as well as within them, and that could also be within the page header or footer. From observation I believe that it may be this latter that caused the freeze-ups.

3. (added 20 Nov) Images + Tables would also move location through the text from their original place.

4. (added 20 Nov) In the Navigator (F5) Tables, Images, DrawObjects, etc.would be listed out-of-order from their position in the text-flow

Under 7.4.7.2 it currently takes 14 seconds after document load for the system load to fall from 30% to a trivial level. Before the changes above it *never* fell below 30%.

(added 20 Nov): After vast amounts of work to create "Proper" styling, a freshly-loaded document takes 10 seconds before the load falls below 30% (an extra 4 seconds saved on earlier work)

1. Opened 1_Programming-In-Python3.odt in AppImage 7.2.3.2
   (normal load, NOT 30%)

2. Used existing lines in Title page (currently styled as Direct Paragraph) to create styles Subtitle 1, (2, 3)
   (using f11 | Styles actions | New Style from Selection); thus no line on Title page now has Direct formatting

3. Shift+Ctrl+S (save-as) to 2_paragraph-fixes.odt

4. Changed Text Body style to "Below paragraph: 0.50 cm" + single line spacing
   (this matches the original pdf closely)

5. Changed default list + indent to Text Body Indent

My intention at this stage was to discover what it was that was freezing LO solid (and once froze the entire system solid). I *did* find it (a bug in 7.2.3.2, so not the original issue). First, a quick word about 'Direct Paragraph' style + Text-Boxes (TB) in H1, 2, 3 & 4 paragraphs:

The Direct Paragraph Style is the base style for all other paragraph styles. Thus, modifying that Style will affect every other paragraph in the entire document, which may (or may not) be what you want. I was also informed that using it directly as a Style throughout a document increases the processing load due to lack of caching.

Each Heading in the pdf contains a stylistic |||| for H1 headers, ||| for H2 headers, and so on. I used a TB to create these. I was advised to use a Frame instead. So what's the issue here?

TB can NOT be assigned a Style, whereas Frames CAN be assigned a Style. We are going to discover a very weird bug with these TB when we reach H2 edits. Frames also have a bad bug associated with them, but that is for later.

The next stage in these edits is to swap out each header TB for a Frame:

1. Each H1 TB was swapped out for a Frame
   (no problems)

2. Each H2 TB was swapped out for a Frame
   (I did it Chapter-by-Chapter; no problems until I reached Chapter 15)

3. The "Dialog-Style Programs" (p568) + "Main-Window-Style Programs" (p574) (ODT, not PDF) each have a TB that has a daeafb Colour applied to the Area (I do not recall applying them)

4. Changing the TB Area from Colour to None then showed the following option within menu:Edit: "Undo: Sort Shapes"

5. Attempting to Save the change produced the following Error (below), which then prevented any attempt to save the document

6. The identical change to the identical document under 7.4.7.2 showed zero problems

Wot a blooming nightmare.

The changes made to this point DID allow 'normal' 7.4.7.2 to open document with ordinary load after some short moments processing. Battered & bruised I continue.

This sorry tale continues.
...
I can't take much more of this.

Hi alexkemp. We are a GNU/Linux-only household and I homeschool my 6 kids. We used to run Libreoffice on the classroom computer but over the years we've corrupted several documents through seemingly innocent document formatting. LO is a complex beast and seems to house some gremlins.

I finally gave up on Libreoffice and installed Abiword (for word processing) and Gnumeric (for spreadsheets) over a year ago. We never had any problems after that, despite heavy use. If you are fed up with LO and would like to try a less complex solution, Abiword and Gnumeric are both excellent.

https://exactcode.com/recompress/

and if you poke around there you will probably also eventually find yourself somewhere in the T2-SDE website:

https://t2sde.org/kb/3/

full disclosure: no affiliation/association with any referenced, just humble friendly sharing. Excellent! Party On!

To re-iterate: somewhere within a 600 page Writer ODT is *something* that has triggered a weird bug.

A long-time expert on the ask.libreoffice.org website fingered my use of "Default Paragraph Style" as one source for system slowdown (should be "Text Body" / "Body Text" instead). I set out to change every one of the thousands of 'ordinary' (not indented, or list, etc) Default-paragraphs to Text Body-paragraphs. Having got almost halfway through those manual changes, I have:

1. Discovered that LO-7.6.7.2 allowed access to edit + save the odt, although the system was at 30% load throughout

2. Changing the 43 paragraphs in the 'Introduction' / save / re-open caused all the excess load to go away

3. Restarting LibreOffice (after no further changes) the load was back

4. Reaching page 113 of 599 with edits the excess load goes away again.

5. Simply restarting LibreOffice (no further changes) and the load is back.

6. Restarting computer then LibreOffice at page 233, after changing 3 paragraphs LibreOffice freezes & has to be dismissed with prejudice (ps aux | fgrep -i libreoffice then kill -9 4112 4171).

7. At some page before this LibreOffice froze so hard that the entire computer system also froze; it required Ctrl+Alt+F1 (go to the command-line) | login | startx | restart computer)

I can't take much more of this.

Whilst still in the process of fixing all normal paragraphs (by changing them to being styled with "Text Body" rather than "Default Paragraph Style") I've just reached "Chapter 3 Collection Data Types" (page 113 out of 599) and, finally, the system load has switched yet again from being at a constant 30% (1 of the 4 cpu cores constantly fully occupied) to a more normal 2%.

Reaching this state has been my goal. I've done these changes before & reached this blissful condition on that occasion. In my ignorance I thought that all my problems were over until, after many more changes, the whole thing suddenly completely froze up.

On the previous occasion I had zero idea as to what change triggered the LO freeze. This time I am monitoring the results of the changes that I make much more carefully.

Wish me luck.

PS
I got Kernel 6.10 installed from bpo today & that had a harsh computer bug. I could not restart into the kernel because of some blasted error. I had to restart into the old kernel. Together with these LO issues it all seemed completely normal.

1. Some folks reported that it opened fine in old versions of LO:
   PedroReina :: LO-5.0.0.5
   Babarosa :: LO-7.6.7.2

2. I had a strong suspicion that the mantra of 'use the newest version' may be skew-whiff (winXP v winVista, anyone?)

3. From LO AppImages listing I downloaded & installed "LibreOffice-7.2.3.2.basic-x86_64.AppImage"

4. It was pointed out to me on ask lo org that I was "using Direct Paragraph Formatting instead of Body Text" and that "Direct formatting puts stress on Writer because every occurrence must be handled individually whereas style effects can be cached and reused at will"

5. 3_new.odt loaded up under 7.2.3.2 & allowed me to operate LO
   (the load was still 30%, but this time I had full access to LO).

6. I modified the Text Body style to single line-spacing
   (that matches the original document closely).

7. Ctrl-h gave Search+Replace. Using "Paragraph Styles" I searched for "Default Paragraph Style" & replaced with "Text Body"

8. Changing only the paragraphs within the Introduction I saved as 4_paragraph-fix.odt, closed then re-opened.

9. Opening 4_paragraph-fix.odt again all the excess load was magically gone. Good Lord.

Added later:

Going to re-open 4_paragraph-fix.odt I thought to open 7.4.7 & see if it would also open the ODT at less than 30% load. It turned out to be worse than that. LO froze up. What?

Opening 24.8.2 the ODT was at 30% load but *did* allow access to ODT.

I'll change the rest of the paragraphs & see what happens.

Note 1:
In 24.8.2 "Text Body" style has been changed to "Body Text"

Note 2:
The above is the 2nd time that I've been through all this. The first time I changed not just the plain paragraphs but also Tables & SideBars. I got about halfway through & changed something (do not know what) that caused the load to go through the roof & freeze LO solid (this was under 7.2.3.2). This time I'm re-doing it from the beginning, going slowly & saving damn near every minute.

If you encounters anything like this again, you can try to run the program with the nice command and a value of 19 to give it the lowest priority in the scheduler. That might prevent the system becoming unresponsive. Another more fine grained way to contain such beasts use of cpu and memory is with cgroups, but that's a bit more advanced.

I decided to go with an AppImage since that offered the opportunity to use a later version without changing any of the currently installed LO elements. It turned out to be not so much of a success (and then more of a success, see below).

I went through the following steps:

1. $ cd /usr/local/bin

2. $ sudo wget https://appimages.libreitalia.org/Libre … 4.AppImage

3. $ sudo mv LibreOffice-fresh.standard-x86_64.AppImage LibreOffice-24.8.AppImage

4. $ sudo chmod a+x LibreOffice-24.8.AppImage

5. $ LibreOffice-24.8.AppImage --help
   LibreOffice 24.8.2.1 0f794b6e29741098670a3b95d60478a65d05ef13

6. $ sudo cp /usr/share/applications/libreoffice-startcenter.desktop /usr/share/applications/loappimage-startcenter.desktop

7. $ sudo nano /usr/share/applications/loappimage-startcenter.desktop
   (I changed the .desktop name + all Exec lines to begin /usr/local/bin/LibreOffice-24.8.AppImage, but pretty much every else was left unchanged)

The new launch link was immediately within menu:Office | LO AppImage Start Centre & showed the correct LO version.

I launched 3_new.odt and GOOD LORD yes! I was able to navigate around the file & travel from top to bottom.

It was still troubling. LO was having problems with the page display at the bottom of the file. The number of pages showing in the Status Bar at bottom left, and also on each page, kept changing. In addition, Figure 15.1 (it is an image & can be viewed safely in the PDF) kept appearing at the top of the bibliography & also other pages, each one well out of place.

Since it seemed stable I asked for the file to be saved. Everything seemed fine & at a normal speed until almost at the very end, when LO & the screen froze. It stayed like that for some time & I had to force-close it. So, no change.

I did not make any changes to the file before saving.

2nd try:

Ran the whole thing again as to be able to discover the name of the image that kept appearing out of order near the bottom of the file (Fig 15.1) (it kept shifting in the display from page-to-page from moment to moment). I noticed that a single core (1 of 4) was active all the time. Also, that the LO version was GTK.

Then I noticed that the usage had dropped from 30% to a more-normal figure. I tried Save again & this time LO both saved it & also completed. I was able to shut the program down normally.

Whoo-hah! This version of LO is hardly working the way that it is supposed to with an ODT, but it seems that I may have use of the file back again, so many thanks to all who responded.

The following pages were also of assistance:

• https://forums.debian.net/viewtopic.php?t=158795

• https://www.libreoffice.org/download/appimage/

Update Nov 7: display fixes

I download LO 7.6.7.2 from here:
https://downloadarchive.documentfoundat … 6.7.2/deb/

Decide if you need x86 or x64 (the latest working version for x86 is 6.2.8.2).
You need the main package and the language file, maybe you also like the help file.

First unpack the main package to your home folder.
In a terminal enter:
cd Libre*
cd DEBS
sudo dpkg -i *.deb
delete the folder Libre... (because the other packages also start with the name Libre...)

Next unpack the language package to your home folder.
Repeat the former commands by using your keyboard's up cursor.
cd Libre*
cd DEBS
sudo dpkg -i *.deb
delete the folder Libre... (because the other packages also start with the name Libre...)

Finally unpack the help package to your home folder.
In a terminal enter:
cd Libre*
cd DEBS
sudo dpkg -i *.deb
delete the last final folder Libre...

Then LO should appear as several starters in your menu bar.

# apt list libreoffice*

There the backports packages are present. The solution for the complete package is e.g. libreoffice-gtk4 or libreoffice-qt6. There are no single packages for writer.

Anyhow: nothing from backports is installed automagically. Pinning makes sure backports doesn't have highest prio. If you want to install something from backports, you need to specify that by using:

# apt -t daedalus-backports install $Packagename

Daedalus backports has 24.8.2

OK, now I'm confused.

That is why I did an 'apt search', so that I could get advised of the range of different LO versions available. And it only offered me 7.4.7. Yet I've already got backports in my listing:

$ grep ^[^#] /etc/apt/sources.list /etc/apt/sources.list.d/*
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus                  main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-updates          main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-security         main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-proposed-updates main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-backports        main non-free-firmware non-free contrib
/etc/apt/sources.list.d/josm.list:deb https://josm.openstreetmap.de/apt/ alldist universe

I run an update every day, but I've never been offered 24.8.2.

So, how would I tell it to update from backports (or have I pinned it somehow)?

Added later:

I've looked at the search listing (which is huge) more closely & have discovered a number of bpo, but the main element appears missing. Here is the closest:

• libreoffice-uiconfig-writer/stable-backports 4:24.8.2-1~bpo12+1 all
    UI data ("config") for LibreOffice Writer

What I mean by 'main element' is a straightforward "libreoffice-writer" etc, which is present for 7.4.7 but not 24.8.2. I think that an error has been made.

I think that I shall try to install an AppImage & pray that there are no systemD viruses tucked in there.

7.6.7 only is available as direct download from https://downloadarchive.documentfoundat … ffice/old/. If you do not trust the backports version, that would be an alternative. If you want I can describe what you need to do to remove 7.4.7 and to install 7.6.7.

Your post is the most hopeful for me so far.

I've tried "apt search libreoffice" & absolutely everything that came up is 7.4.7 (same as I currently have).

How did you install 7.6.7? Is it installed concurrent with 7.4.7 or instead of?

It sounds crazily ironic that v5.0.0 & v7.6.7 both can open this ODT yet v7.4.7 freezes solid.