Bug 109200 - Draw seems to lock, calls sbrk() like crazy, and takes 5' opening a pdf
Summary: Draw seems to lock, calls sbrk() like crazy, and takes 5' opening a pdf
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, perf
Depends on:
Blocks: PDF-Import-Draw
  Show dependency treegraph
 
Reported: 2017-07-19 07:47 UTC by Jiri Slaby
Modified: 2023-04-28 09:21 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
pdf to reproduce (506.31 KB, application/pdf)
2017-07-19 07:47 UTC, Jiri Slaby
Details
thread apply all bt in gdb when this happens (9.72 KB, text/plain)
2017-07-19 07:49 UTC, Jiri Slaby
Details
thread apply all bt in gdb when this happens with debuginfo installed (11.28 KB, text/plain)
2017-07-19 08:01 UTC, Jiri Slaby
Details
perf report of draw (2.92 KB, text/plain)
2020-03-06 12:15 UTC, Jiri Slaby
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Slaby 2017-07-19 07:47:00 UTC
Description:
When I open the attached pdf in draw, it spins infinitely. Opening other pdfs seems to be OK, though.

Steps to Reproduce:
1. open the pdf

Actual Results:  
draw is spinning on CPU

Expected Results:
pdf is opened.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Jiri Slaby 2017-07-19 07:47:22 UTC
Created attachment 134723 [details]
pdf to reproduce
Comment 2 Jiri Slaby 2017-07-19 07:49:39 UTC
Created attachment 134724 [details]
thread apply all bt in gdb when this happens

I do not have debug symbols installed because there are none available on opensuse AFAICS.
Comment 3 Jiri Slaby 2017-07-19 08:01:32 UTC
Created attachment 134725 [details]
thread apply all bt in gdb when this happens with debuginfo installed

In the end, I updated to 5.4.0.2 from LibreOffice:Factory project:
https://build.opensuse.org/package/show/LibreOffice:Factory/libreoffice

and there is also debuginfo. So the backtrace shows, that we are spinning in pdfi::PageElement::resolveUnderlines.
Comment 4 Xisco Faulí 2017-07-19 09:08:43 UTC
Confirmed in

- Version: 6.0.0.0.alpha0+
Build ID: ddadcb4f4a2bc6538c219a0a577bdf5999015150
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

- Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e

- LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 5 QA Administrators 2018-07-25 02:41:13 UTC Comment hidden (obsolete)
Comment 6 Jiri Slaby 2018-07-26 12:39:47 UTC
Still happens with 6.1.0.1.
Comment 7 QA Administrators 2019-07-30 03:13:05 UTC Comment hidden (obsolete)
Comment 8 Jiri Slaby 2019-07-31 11:37:43 UTC
Still happens with 6.2.5.2.
Comment 9 Gerald Pfeifer 2020-03-06 00:15:26 UTC
On my four year old notebook, at T450 with Intel Core i7-5600U CPU @ 2.60GHz
LibreOffice 7.0 alpha manages to open this after 5 minutes.

An strace shows a long list of calls to sbrk().

Is this an improvement, or did you not wait that long (or used a significantly
slower machine)?
Comment 10 Jiri Slaby 2020-03-06 09:12:57 UTC
(In reply to Gerald Pfeifer from comment #9)
> Is this an improvement, or did you not wait that long (or used a
> significantly
> slower machine)?

Oh really -- it takes ~ 5 mins, I never waited for that long.

libreoffice-6.4.1.1-1.1.x86_64
Comment 11 Jiri Slaby 2020-03-06 12:15:17 UTC
Created attachment 158444 [details]
perf report of draw

According to these perf measurements, Draw seems to spend significant time in pdfi::PageElement::resolveUnderlines which contains this FIXME:
    // FIXME: currently the algorithm used is quadratic
    // this could be solved by some sorting beforehand


That function searches the document for horizontal lines and removes them if they underline some text (and makes the text underlined instead). Well, the document contains many horizontal lines.

The algorithm should be optimized or should time out after a while (not 5 minutes).
Comment 12 QA Administrators 2022-03-07 03:29:21 UTC Comment hidden (obsolete)
Comment 13 Gerald Pfeifer 2022-03-07 08:16:58 UTC
Still slooow with (mostly) current -dev builds:

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 2b924f0d83ce63882e7d14a2b51cc645c2532920
CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Comment 14 Roman Kuznetsov 2023-04-27 11:09:47 UTC
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5cd9de202765e243e41416802f3e4486b8a96f16
CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL threaded

opens the PDF instantly

closed as WFM
Comment 15 Gerald Pfeifer 2023-04-28 09:21:12 UTC
Still slow in 6.4.8.0.0, 7.2.8.0.0, and

  Version: 7.4.8.0.0+ / LibreOffice Community
  Build ID: 603f915294a10f11b4199dfd28704a77f4e05abd
  CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: gtk3
  Locale: en-US (en_US.UTF-8); UI: en-US

with with ~113s for the latter on my i5-10210U CPU @ 1.60GHz system
(which is three years old, cf. comment #9 for older measurements on
an older system).


  Version: 7.5.2.0.0+ (X86_64) / LibreOffice Community
  Build ID: bad4f41a69fe3fb08191b839f0c9389683685855
  CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: gtk3
  Locale: en-US (en_US.UTF-8); UI: en-US

and

  Version: 7.5.4.0.0+ (X86_64) / LibreOffice Community
  Build ID: f794d79a334413dd1e5c4f4997d11047170024ef
  CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: gtk3
  Locale: en-US (en_US.UTF-8); UI: en-US

are indeed down to about 5, 6 seconds, as is current head

  Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
  Build ID: 2e57755f72907e4bb604a8ba32edbd6c253ee57c
  CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: gtk3
  Locale: en-US (en_US.UTF-8); UI: en-US

In other words, this likely was addressed in earlier 7.5 development.