Bug 82143 - VIEWING: 100% CPU while Scrolling a specific document
Summary: VIEWING: 100% CPU while Scrolling a specific document
Status: RESOLVED DUPLICATE of bug 118104
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: filter:docx, haveBacktrace, perf
Depends on:
Blocks: Performance CPU-AT-100% tdf#114306-regressions
  Show dependency treegraph
 
Reported: 2014-08-04 17:35 UTC by Johannes Nickel
Modified: 2024-04-25 06:39 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
linux backtrace (31.69 KB, text/plain)
2014-08-05 23:09 UTC, Yousuf Philips (jay) (retired)
Details
Sample documents (705.45 KB, application/zip)
2018-12-10 11:31 UTC, George Sofianos
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Nickel 2014-08-04 17:35:32 UTC
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
Comment 1 Yousuf Philips (jay) (retired) 2014-08-05 06:25:27 UTC
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.
Comment 2 Johannes Nickel 2014-08-05 06:42:06 UTC
Mail and link to a "GIF" Screencast send to you mail.

Thanks!
Comment 3 Yousuf Philips (jay) (retired) 2014-08-05 07:53:14 UTC
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. :)
Comment 4 Jean-Baptiste Faure 2014-08-05 17:27:54 UTC
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
Comment 5 Yousuf Philips (jay) (retired) 2014-08-05 23:09:49 UTC
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.
Comment 6 Johannes Nickel 2014-08-07 07:39:12 UTC
(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". :(
Comment 7 Yousuf Philips (jay) (retired) 2014-08-07 18:59:20 UTC
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.
Comment 8 Björn Michaelsen 2014-08-21 12:21:19 UTC Comment hidden (obsolete)
Comment 9 Robinson Tryon (qubit) 2015-12-10 07:41:03 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2017-01-03 19:42:31 UTC Comment hidden (obsolete)
Comment 11 Volga 2017-01-28 15:31:48 UTC
Yousuf Philips, what happened when you try it on a machine with multi core/thread CPU?
Comment 12 Volga 2017-01-28 15:33:31 UTC
Also, what about GPU?
Comment 13 Yousuf Philips (jay) (retired) 2017-01-28 17:54:31 UTC
(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?
Comment 14 Aron Budea 2017-01-28 22:44:00 UTC
(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
Comment 15 George Sofianos 2017-11-21 11:04:28 UTC
Hi, I'm having the same problem, is there a workaround for this?
Comment 16 Marc Schipperheyn 2018-12-08 12:50:41 UTC
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.
Comment 17 Marc Schipperheyn 2018-12-08 12:51:35 UTC
That should be version: 6.1.3.2
Comment 18 Jean-Baptiste Faure 2018-12-10 06:15:49 UTC
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
Comment 19 Xisco Faulí 2018-12-10 11:16:23 UTC
(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...
Comment 20 George Sofianos 2018-12-10 11:31:13 UTC
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
Comment 21 Telesto 2018-12-10 11:45:05 UTC
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
Comment 22 Buovjaga 2018-12-10 11:50:53 UTC
(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.
Comment 23 Jean-Baptiste Faure 2018-12-10 11:54:54 UTC
(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
Comment 24 Buovjaga 2018-12-10 11:58:49 UTC
(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.
Comment 25 Xisco Faulí 2018-12-12 17:11:29 UTC
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
Comment 26 Xisco Faulí 2019-01-23 23:24:27 UTC
(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 ***