--- Begin Message ---
Package: libreoffice-writer
Version: 1:7.0.4-4+deb11u3_bpo10+1
Severity: important
When editing a Document in Libreoffice everything is fine, even when it's a very large document > 150 pages and this lasts some hours. But the behaviour described below is independent of document size.
When minimising the Libreoffice window, or putting it into background, while working in other program windows, after an arbitrary period CPU load raises to 100%, causing cooling fan to run at constant highest speed and slowing down your work remarkably. Sometimes this starts after some minutes already, sometimes after some hours only after the Libreoffice window was lost focus. It is unpredictable. Workaround for this I found is to maximise or restore or make active Libreoffice window, which will stop the 100% load immediately, going down to the default 1% to 5 % system load. It will happen again and again, independent of which document is edited. This behaviour is quite anoying when working in multiple documents/drawings at the same time or when an internet research is needed to complete a text document, or an image is to be prepared for the document in between, since you can't predict when Libreoffice starts going mad. It happens even when working in two Libreoffice Writer documents parallel in two windows. If the first window has not the focus, libreoffice will stall after some time.
Once it has started this, you can repeatedly switch the windows, causing allways the CPU go up to 100% and switching from 800MHz to 1,7GHz mode, if the first Libreoffice Writer window looses focus, either by minimising it or by activating any another window, so the Libreoffice window concerned is in background, and CPU is going back to normal immediately always when first Libreoffice Writer window gets active again.
Example:
activate the 1st Libreoffice window → 2% System load (0% soffice.bin)
activate any other window including 2nd Libreoffice document windows: → 100% System load (98% soffice.bin)
activate the 1st Libreoffice window → 2% System load (0% soffice.bin)
activate any other window including 2nd Libreoffice document windows: → 100% System load (98% soffice.bin)
activate the 1st Libreoffice window → 2% System load (0% soffice.bin)
minimise to tray the 1st Libreoffice window → 100% System load (98% soffice.bin)
activate the 1st Libreoffice window → 2% System load (0% soffice.bin)
and so on...
No other program I know of shows this or a similar behaviour for me.
Now I found out it can get set back temporarly to accept not having the focus by re-saving the document, even when nothing has been changed since the last saving. Then the CPU load will stay for some time at normal again, but again after an arbitrary period the issue will start anew, exactly as described above. You can repeat this also unlimited times, so no proper work is possible.
—This also happens when running Libreoffice in protected mode exactly the same.
—The behaviour is independend of size of the document.
—It happens with all documents.
–This is not restricted to Writer, same happens to Calc. Other Libreoffice components may be affected also.
—Nice down soffice.bin doesn't change things, but prevents at least other programs from being slowed down by this exorbitant CPU usage of Libreoffice, so system stays responsible.
—When Libreoffice is ideling in its document selection launch (where you can select previously used documents from a screen) without a document being opened in one of its components, this issue doesn't happen at all.
Looks possibly like a regression of a bug reported in 2020 already for an older Libreoffice release:
#964549
And also this even older report (from 2018) might be of some interest:
https://bugs.documentfoundation.org/show_bug.cgi?id=117684
Please, could you finally fix this issue? It's annoying and keeps from using Libreoffice, since it drains notebook accu.
Technical data:
Libreoffice (as reported by "about" in GUI) :
Installed version:
Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 1; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Debian package version: 1:7.0.4-4+deb11u3_bpo10+1
Calc: threaded
$ apt-cache policy libreoffice* | grep -v '(keine)' | grep -B1 Installiert
libreoffice-math:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-gtk3:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-core:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-l10n-de:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-base-core:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-impress:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-help-de:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-help-common:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-style-colibre:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-writer:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-common:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-calc:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libreoffice-draw:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
ucf:
Installiert: 3.0038+nmu1
libabw-0.1-1:
Installiert: 0.1.2-1
libc6:
Installiert: 2.28-10+deb10u1
libe-book-0.1-1:
Installiert: 0.1.3-1+b2
libepubgen-0.1-1:
Installiert: 0.1.1-1
libetonyek-0.1-1:
Installiert: 0.1.9-1
libgcc1:
Installiert: 1:8.3.0-6
libicu63:
Installiert: 63.1-6+deb10u3
liblangtag1:
Installiert: 0.6.2-1
libodfgen-0.1-1:
Installiert: 0.1.7-1
librevenge-0.0-0:
Installiert: 0.0.4-6
libstaroffice-0.0-0:
Installiert: 0.0.6-1
libstdc++6:
Installiert: 8.3.0-6
libuno-cppu3:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libuno-cppuhelpergcc3-3:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libuno-sal3:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libuno-salhelpergcc3-3:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
libwpd-0.10-10:
Installiert: 0.10.3-1
libwpg-0.3-3:
Installiert: 0.3.3-1
libwps-0.4-4:
Installiert: 0.4.10-1
libxml2:
Installiert: 2.9.4+dfsg1-7+deb10u4
uno-libs-private:
Installiert: 1:7.0.4-4+deb11u3~bpo10+1
zlib1g:
Installiert: 1:1.2.11.dfsg-1+deb10u2
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
$ uname -r
4.19.0-256-antix.1-686-smp-pae
$ lscpu
Architecture: i686
CPU op-mode(s): 32-bit
Byte Order: Little Endian
Address sizes: 32 bits physical, 32 bits virtual
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 13
Model name: Intel(R) Pentium(R) M processor 1.73GHz
Stepping: 8
CPU MHz: 1333.000
CPU max MHz: 1733,0000
CPU min MHz: 800,0000
BogoMIPS: 2659.88
NUMA node0 CPU(s): 0
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx bts cpuid est tm2 pti
$ free
total used free shared buff/cache available
Mem: 2055396 456036 957976 152364 641384 1229508
Swap: 2265128 963136 1301992
--- End Message ---
--- Begin Message ---
Version: 1:7.4.1-1
Hi,
Am 28. Oktober 2022 07:03:22 MESZ schrieb Robin <robin.antix@yahoo.com>:
>Hi all!
>
>Good news:
>
>The Libreoffice backport from bookworm seems to fix this issue.
Good.
Closing this then with the appropriate version. The BTS version Tracking knows the affected versions and they will appear as such.
>Maybe you can transfer the fix to the stable bullseye version,
If one knows the actual fix, but yeah in theory it's possible
> in order to get security updates (above you've stated there are none on backports, which would be bad).
Nah, you misunderstood. No direct ones they get the updates from the base distro. (In your case buster got the bullseye security update we rebuilt, bullseye-backports got 7.4.1)
Just that buster is out if support so I might not do it anymore at some point in time (especially if it gets closed somewhen which is already some plan.)
Regards
René
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--- End Message ---