Description: When working on large documents (e.g. in writer, 200 pages of text with two dozen or so images) the soffice.bin process persistently shows a 100% CPU load. Closing all documents solves the problem, reopening them restores it, but not immediately. This occurred with previous versions on Ubuntu Linux 12.04 (old laptop with single core and little memory) and still occurs on Ubununtu Linux 18.04 (new laptop with 8 gig RAM and quad core I5). This is not trivial as it reduces battery life on my laptop from 6.5 to 2.5 hours or less. No advanced settings have been found to affect the problem or provide a solution. The system has enough spare RAM that swap file usage is minimal and core memory usage is within normal limits. Excess memory allocation would force the system into swapping, but this is not the case; it's a CPU load issue only. Steps to Reproduce: 1. Start LO 2. Open or create a large document or several large documents (100+ pages with some images) in Write or large, complex spreadsheets (1000+ cells in Calc) Actual Results: After some time (but not immediately) you will notice that something is causing a high CPU load. This invariably turns out to be the soffice.bin process which holds a single core at 100% regardless of activity. Close all documents. CPU load will immediately drop to sensible levels (a few percent). Reopen documents, wait a while, and high CPU load reoccurs (but once again, not immediately) Expected Results: CPU load should be a factor of application task load, not of memory consumption. When SO is completely idle, the soffice.bin process should not show a constant 100% CPU load Reproducible: Always User Profile Reset: Yes Additional Info: Version: 6.0.3.2 Build ID: 1:6.0.3-0ubuntu1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-ZA (en_US.UTF-8); Calc: group Sample output of 'top' command (see soffice.bin process at top of list): top - 10:31:17 up 7 days, 1:20, 1 user, load average: 1.72, 1.51, 1.60 Tasks: 384 total, 2 running, 292 sleeping, 0 stopped, 1 zombie %Cpu(s): 12.2 us, 0.7 sy, 0.0 ni, 86.9 id, 0.1 wa, 0.0 hi, 0.1 si, 0.0 st KiB Mem : 8029492 total, 172296 free, 6218896 used, 1638300 buff/cache KiB Swap: 33203196 total, 32590968 free, 612228 used. 1322736 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 397 frankvw 20 0 8587332 907868 113896 R 100.0 11.3 1318:06 soffice.bin 1745 frankvw 20 0 1328980 191504 159260 S 1.7 2.4 83:51.15 Xorg 2416 frankvw 20 0 655160 34808 24744 S 1.0 0.4 32:21.19 indicator-+ 17572 frankvw 20 0 668976 27500 15856 S 0.7 0.3 0:01.81 gnome-term+ 339 frankvw 20 0 51468 3940 3076 R 0.3 0.0 0:00.12 top
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Thank you for responding. Uploading the documents I've been working with is going to be tricky; they all contain proprietary information and I can't release them. I'll see if I can generate a different document (structured and sized similarly) that will trigger the problem. I'll change the bug status once I have managed to do so.
try to uncheck "spellchecking when typing", maybe this is the cause off the high cpu load and high memory use
Disabling spell checking while typing has no effect. Note that the constant 100% cpu load of soffice.bin also occurs when no text is being typed at all.
Is it reproducible if you try in safe-mode ? Help - Restart in safe mode
After running in sae mode for several days the problem has not recurred. So yes, it can be solved by running in safe mode.
Thanks for testing in safe mode. It means it's a corrupted profile causing the issue. Closing as RESOLVED WONTFIX