Problem description: If I or one of my colleagues open a specific document Libre Office goes to 100% CPU and is extremely slow. It appears if we are around page 12 of the document. I did not managed it to reproduce this bug with another document. Steps to reproduce: Open the document. The problem is, the document contains data I can not publish here. Is there any other way to send this direct to someone? The document itself conatins some screenshots but the overall size is about 1,3 MB. We tried it on Mac, Linux and Windows. Everywhere the same behaviour. Current behavior: 100% Load, extremely slow scrolling, long waiting times. Expected behavior: "normal" loading times, smooth scrolling. Operating System: All Version: 4.3.0.4 release Last worked in: 4.2.4.2 release
Hi Johannes, Thank you for reporting this bug. You can directly send it to me as a separate email so that its not placed in the public.
Mail and link to a "GIF" Screencast send to you mail. Thanks!
Hi Johannes, Thanks for the email. I can confirm that this behaviour effects 4.4 (master), 4.3.1, 4.2.5, 4.1.6 and 3.3.0 on Windows 7 and master on Linux. When the document is loaded, after 10 seconds the CPU hits 50% and the UI freezes for a minute or two. Then i switch the document to single page mode and clicked the scroll bar to jump page by page. Once i hit page 11 or 12, the CPU is again at 50% and the UI freezes. I let it run for 15 minutes before cancelling it. @Meeks: Is a backtrace needed for this one. :)
Hi Johannes, Please could you try to rename all confidential data with X character and try again? If you still encounter the same problem with the modified file, please attach it to this bug report. Best regards. JBF
Created attachment 104110 [details] linux backtrace I've run a backtrace, hoping that it will be sufficient, and have attached it. Had to kill the process at the console during its hang period.
(In reply to comment #4) > Hi Johannes, > > Please could you try to rename all confidential data with X character and > try again? If you still encounter the same problem with the modified file, > please attach it to this bug report. > > Best regards. JBF I'm sorry but I'm not able to edit the document. Everything I try ends up in 100% CPU and "no response". :(
I was able to convert the file to pdf and when i opened it up and got to page 12, the CPU jumped to 50% and okular took 30s to load the page, but still after that the CPU ran at 50% for another 20s. Didnt see anything on the page except for text and an image after it rendered.
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
Migrating Whiteboard tags to Keywords: (filter:odt, perf)
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
Yousuf Philips, what happened when you try it on a machine with multi core/thread CPU?
Also, what about GPU?
(In reply to Volga from comment #11) > Yousuf Philips, what happened when you try it on a machine with multi > core/thread CPU? The CPU i tested on had 2 cores/threads, which is why the overall CPU hit 50%, meaning one of the CPU cores/threads was at 100%. I tested a recent build and there are still freezing issues when the document loads and then my entire system seems to freeze when i scroll to around page 7 or so. Version: 5.3.0.1.0+ Build ID: d1b8074ffe4b945a41e3ad9e1fb43332d78d73fb CPU Threads: 2; OS Version: Linux 3.19; UI Render: default; VCL: gtk2; Layout Engine: new; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-3, Time: 2017-01-10_23:02:10 Locale: en-US (en_US.UTF-8); Calc: group Opened the doc with Calligra Words and after a few minutes of loading and a CPU core at 100%, the document was viewable and scrollable without problems. @Xisco, @Aron, @Bouvjaga: I've shared the document with you guys privately on google docs for testing. Initially i thought images may be causing the issue, but deleting all the images from the doc still didnt solve the issue. @Meeks: Document also shared with you privately on google docs, so does a valgrind or callgrind need to be done on the doc to find out where the problem is?
(In reply to Yousuf Philips (jay) from comment #13) > I tested a recent build and there are still freezing issues when the > document loads and then my entire system seems to freeze when i scroll to > around page 7 or so. I see dynamic-cast-related code taking up a lot of runtime, and the execution going in a neverending circle into/inside of: const SdrObject *SwOrderIter::Next() The dynamic casts are this: if ( m_bFlysOnly && dynamic_cast<const SwVirtFlyDrawObj*>( pObj) == nullptr ) http://opengrok.libreoffice.org/xref/core/sw/source/core/layout/frmtool.cxx#2219
Hi, I'm having the same problem, is there a workaround for this?
I see the same behavior making working with LibreOffice a bit of a nighthmare Version: 6.3.2 Document type: Microsoft Word docx with comments. No images Computer: MBP2018 15 inch With openGL disabled - scrolling speed is perhaps 50fps. It's workable but not smooth, the scrolling is a bit janky. with openGL enabled - scrolling speed is perhaps 30fps. choppy. with the screen catching up all the time to the scrolling intent Neither is acceptable.
That should be version: 6.1.3.2
Well, without a public test file, I think this bug report is completely useless. Each tester can put whatever he want behind "specific document" and it is impossible to know if the problem has the same root cause than the firstly reported. Nothing can be done with a private document if it is not in the hands of a developer. Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #18) > Well, without a public test file, I think this bug report is completely > useless. Each tester can put whatever he want behind "specific document" and > it is impossible to know if the problem has the same root cause than the > firstly reported. Nothing can be done with a private document if it is not > in the hands of a developer. > > Best regards. JBF I agree! @Johannes Nickel, Please provide a sample document to reproduce this issue...
Created attachment 147417 [details] Sample documents I'm attaching some sample documents. At the moment sample1 is freezing my libreoffice writer when scrolling, but it might depend on the CPU. Please delete the sample when this is done
Tested sample1.docx Repro with Version: 6.3.0.0.alpha0+ Build ID: beae6c7a7f163daad0d4dea63a3d403af2745fd1 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-12-06_23:55:16 Locale: en-US (nl_NL); UI-Language: en-US Calc: CL but not with Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
(In reply to Telesto from comment #21) > Tested sample1.docx > > Repro with > Version: 6.3.0.0.alpha0+ > Build ID: beae6c7a7f163daad0d4dea63a3d403af2745fd1 > CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; > TinderBox: Win-x86@42, Branch:master, Time: 2018-12-06_23:55:16 > Locale: en-US (nl_NL); UI-Language: en-US > Calc: CL > > but not with > Versie: 4.4.7.2 > Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 > Locale: nl_NL Just so we don't forget: now we are no longer dealing with the original issue that was seen in 3.3.0 already.
(In reply to Buovjaga from comment #22) > [...] > Just so we don't forget: now we are no longer dealing with the original > issue that was seen in 3.3.0 already. Indeed, so to make things clear, we should close this bug report as InsufficientData and open a new bug report with the test file provided in comment #20. Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #23) > (In reply to Buovjaga from comment #22) > > [...] > > Just so we don't forget: now we are no longer dealing with the original > > issue that was seen in 3.3.0 already. > > Indeed, so to make things clear, we should close this bug report as > InsufficientData and open a new bug report with the test file provided in > comment #20. I recommend doing the bibisect first, then searching with the hash for a previously reported issue. Maybe it has already been reported.
The hang with sample1.docx was introduced with https://cgit.freedesktop.org/libreoffice/core/commit/?id=18765b9fa739337d2d891513f6e2fb7c3ce23b50, which is already reported in bug 118104. Closing this issue as RESOLVED INSUFFICIENTDATA
(In reply to Xisco Faulí from comment #25) > The hang with sample1.docx was introduced with > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=18765b9fa739337d2d891513f6e2fb7c3ce23b50, which is already reported in > bug 118104. > Closing this issue as RESOLVED INSUFFICIENTDATA Closing as a DUPLICATE of bug 118104 so we can track of it *** This bug has been marked as a duplicate of bug 118104 ***