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.
The root cause is the structure of the document itself. That large block of hanzi at the end isn't so simple: it's broken up into thousands of tiny spans. The formatting looks something like this: > Style sets language to en-US > 2-6 character run > DF sets language to en-US > 2-6 character run > DF unsets language > 2-6 character run > DF sets language to en-US > 2-6 character run > DF unsets language > ... (repeat thousands of times) The structure isn't exactly like this, but that's the general idea. There's a checkerboard of direct formatting which doesn't affect document semantics, but differs just enough from span to span that we don't treat it as contiguous text. Combine this with a tiny font size that puts all of these spans on screen at the same time, and we naturally get the observed performance characteristics. Metadata suggests this document may have been generated by Kingsoft Office/WPS Office. Word doesn't seem to produce documents like this. If you re-save this document in Word, all of the unnecessary language DF is automatically stripped from the file (and the bug no longer reproduces). I created a candidate patch which adds the same performance optimization to Writer. Repeating the PDF export test from comment 17 gives the following results: real 0m12.265s user 0m10.078s sys 0m0.202s Within the UI, the performance difference feels larger. Previously, trying to view or scroll on the last page would freeze on my machine for around 10 seconds. With the patch, scrolling on the last page now feels the same as the rest of the document.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/22152fd1278110bc625f5ad535f7f03a52e69ddb tdf#117636 sw: Ignore spurious language spans in DOC files It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.