Description: CPU 100% when I convert office document to pdf, using this command: /usr/bin/libreoffice --invisible --convert-to pdf xxx.docx. I test many files; Steps to Reproduce: 1.open ubuntu terminate 2.input this command : /usr/bin/libreoffice --invisible --convert-to pdf xxx.docx 3.excuate and look at the cpu usage Actual Results: the cpu usage is normal Expected Results: the cpu 100% Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36
What is the problem? CPU is made to be used, no? Did you mean that the PDF export take too long time? Status set to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided. Best regards. JBF
Please also test with master when reporting bugs: https://dev-builds.libreoffice.org/daily/master/. Please compare some older LO which worked fine, current 6.0.4 and master.
(In reply to Jean-Baptiste Faure from comment #1) > What is the problem? CPU is made to be used, no? > Did you mean that the PDF export take too long time? > > Status set to NEEDINFO, please set it back to UNCONFIRMED once requested > informations are provided. > > Best regards. JBF 1.the cpu usage is 100+% when I convert office document to pdf; 2.the PDF export take too long time.
(In reply to Timur from comment #2) > Please also test with master when reporting bugs: > https://dev-builds.libreoffice.org/daily/master/. > Please compare some older LO which worked fine, current 6.0.4 and master. I have installed and tested version 4.2.0 ~ 5.4.6 ~ 6.0.4. All have the problem;
Tested with docx, no problem here. Please attach an example document. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document.
(In reply to Buovjaga from comment #5) > Tested with docx, no problem here. > > Please attach an example document. > Set to NEEDINFO. > Change back to UNCONFIRMED after you have provided the document. Steps to Reproduce: 1.open ubuntu terminate 2.input this command : /usr/bin/libreoffice --invisible --convert-to pdf xxx.docx 3.excuate and look at the cpu usage This will happen on any large file.
(In reply to zyl from comment #6) > This will happen on any large file. OK, but as you have the files, please attach an example one. I already tried with a file and did not see the problem after all.
Created attachment 144683 [details] the result of command
Created attachment 144684 [details] the test doc
Actually the file hangs at import time Version: 6.2.0.0.alpha0+ Build ID: bf8fbbaa683ef7eef5f9587b60486f622b50cb80 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
Re: previous comment: the file does not hang upon opening, it is just slow. (In reply to zyl from comment #9) > Created attachment 144684 [details] > the test doc Thanks. The file is very slow to open in GUI as well. The reason is the massive amount of Chinese glyphs (continuous) starting at page 63. If I remove all of those last pages, it is very quick. Saving the original .doc to .odt seems to make the opening a bit quicker, but the perf is still horrible when scrolling to the last pages. Version 3.3.0 says error it is not a doc. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 3c86ffd8ded628e6f2b4187948a1b1056f6a0f56 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on September 5th 2018 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
Created attachment 145125 [details] Callgrind output from master Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 0ffa7a733d834647dfd59b864c52a015028822b6 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on September 21st 2018
Dear zyl, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I CONFIRM the issue: it's impossible to open the .doc because LO hangs at importing it Version: 6.3.1.2 Build ID: 6.3.1-1 CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3; Locale: it-IT (en_GB.UTF-8); UI-Language: en-GB Calc: threaded
Dear zyl, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear zyl, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The fix for bug 64991 improved the situation significantly, both when scrolling through most of the document, and in PDF export: Original: real 1m12.863s user 1m10.654s sys 0m0.201s With fix: real 0m39.827s user 0m37.679s sys 0m0.165s Performance is still abysmal when viewing the microscopic print at the end of the document. I tried to reproduce the issue by hand in the same document, but I couldn't. A simple cut+paste with the same formatting is enough to prevent it. This suggests we're setting up some sort of pathological behavior in the DOC import code. As with bug 64991, it's possible that the root cause won't be detectable via profiling.