Description: On two different computers running Ubuntu 16.04, and LibreOffice 6 (now on version: 6.0.4.2 Build ID: 1:6.0.4~rc2-0ubuntu0.16.04.1 When I have Writer documents open in the background, and occasionally (can happen several times a day) soffice.bin uses 100% CPU. I found that clicking on the save button in all documents brings CPU usage down to normal - even when the document has been saved and not modified previously (in other words, even if the save button is not showing a red dot). I could not figure out why this happens sometimes but not others, a day might go by without problem even with several docs open. Also, does not seem to depend on document format. I mainly use Writer, so not sure if it happens with other components. The problem started after I upgraded from a LO version 5 to 6. Steps to Reproduce: 1. open Writer documents 2. wait 3. check CPU usage (or fan noise) 4. try saving documents to bring CPU usage down Actual Results: CPU at 100% Expected Results: CPU usage normal Reproducible: Sometimes User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
@Geoffrey, thank you for your report. Could you provide the documents which cause the issue, as well as the configuration of your machine when the problem arises (e.g., RAM/Processor - both total and usage at the time of the issue)? Setting to NEEDINFO. When the request information is provided, please, move back to UNCONFIRMED.
I have tried to identify files that cause the problem, but could not single out any. A document might be causing the issue one day, but the next day another document is causing the problem. So I am now almost sure that it is not specific documents that are causing this - nor file formats, it happens with .doc, .odt, .docx. When left for a period of time, soffice.bin uses between 97 and 102% CPU. This stops (temporarily) when I either save, or close, the document causing the issue. After a period of time, it might be another document causing the problem. The processor on one of the computers is an Intel Core i5-5200U CPU @ 2.20GHz × 4 (the other computer is an i7 2.5GHzx4)
You could try letting it run in Safe mode and see, if the problem surfaces with it as well. You can launch it from the command line with libreoffice --safe-mode or Help - Restart in safe mode and then Continue in safe mode.
Confirm. 6.0.6.2 running on gentoo linux with kernel 4.9.76 When running in the background with .doc, .docx, .ppt documents, soffice.bin goes to 100% of one cpu and stays there until I maximize a window. Sometimes it will do this right away when I minimize a window, sometimes it takes a while. Out in the interwebs, the problem is claimed to be associated with gtk2. But I run a KDE system.
(In reply to Jonatham E. Snow from comment #4) > Confirm. 6.0.6.2 running on gentoo linux with kernel 4.9.76 > > When running in the background with .doc, .docx, .ppt documents, soffice.bin > goes to 100% of one cpu and stays there until I maximize a window. Sometimes > it will do this right away when I minimize a window, sometimes it takes a > while. > > Out in the interwebs, the problem is claimed to be associated with gtk2. But > I run a KDE system. In addition to maximizing, does it go away if you save the document (like it does for Geoffrey)?
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Still having this problem, on two different laptops. I tried restarting in 'safe mode' as suggested, on both computers, but the problem persists.
Still having this issue. Using 6.0.6.2
(In reply to Buovjaga from comment #5) > In addition to maximizing, does it go away if you save the document (like it > does for Geoffrey)? Jonatham: I was interested in this information back in October. Would also be interested in hearing your results with an appimage of 6.3 alpha: https://libreoffice.soluzioniopen.com/
Dear Geoffrey, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Geoffrey, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp
Have experienced similar situations in Windows 10, at least up to LO 6.3.3.2, so changed hardware to ALL. Unfortunately, it is not systematic or file-specific - but here is what I notice. 1. Only happens after "sleeping/"hibernating" Windows (leaving LO open with several files open) and then continuing -- but only occasionally, not every time, but sufficiently frequently to be irritating. (not exactly 100% CPU, more like 30%) 2. Sometimes the CPU use can be returned to normal by saving an unsaved document. (there can still be others that are unsaved). 3. Sometimes the CPU use can be returned to normal by closing a saved document. 4. But as noted, no obvious pattern as why this starts or what gets it to stop. Maybe this will remain a NEEDINFO or RESOLVED-INSUFFICIENTDATA.
Setting this to NEW, so it does not go away
(In reply to Geoffrey from comment #0) > I found that clicking > on the save button in all documents brings CPU usage down to normal - even > when the document has been saved and not modified previously (in other > words, even if the save button is not showing a red dot) Have encountered similar cases, where closing an unmodified document will bring CPU usage down. Often (but not always) these documents are long (50+ pages) and have many bookmarks and images. (I thought it could be an interaction with the Windows .NET framework, but I can understand that linux users have same problem.) (will have to try the "save unmodified" technique next time.)
Update: I upgraded to Ubuntu 20.04 in April (now using Libreoffice 6.4.4.2) and I have not had this issue since.
Great, let's close.