Bug 127134 - Dotted lines in tables makes LibreOffice freeze when showed in print preview.
Summary: Dotted lines in tables makes LibreOffice freeze when showed in print preview.
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2019-08-24 00:29 UTC by Marqeaux
Modified: 2021-08-26 12:58 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
dotted lines example (15.41 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-08-24 09:17 UTC, Oliver Brinzing
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marqeaux 2019-08-24 00:29:45 UTC
Description:
I've noticed this behaviour since LibreOffice 6.2: In LibreOffice Calc, when I create a table with dotted lines in the cells, and you want to see a print preview of this, the build-up of this print preview screen gets stuck in an infinite loop, freezes LibreOffice and takes up 100% CPU. This is NOT the case when you use normal lines without dots.

I've seen this behaviour under LibreOffice in Linux distro's (Manjaro 18.0.4 Xfce, Ubuntu 16.04 LTS and Xubuntu 18.04 LTS). I tried to duplicate this behaviour also under Windows 7. Under that platform the dotted lines scenario builds the table up slowly, but after two hiccups it's shown properly.

On both Linux and Windows, OpenGL is disabled. This behaviour is reproduced on both x86 and x86_64 machines.

Steps to Reproduce:
1. Start LibreOffice Calc
2. Create a Calc-document
3. Within that document, create a table with dotted lines
4. In the menu, go to "File" > "Print preview"

Actual Results:
The image gets in an infinite loop, LibreOffice freezes and CPU goes to 100%.

Expected Results:
Builds up the table to be shown as print preview without the as above described behaviour.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
I'm not shure if this behaviour was already present in previous versions of LibreOffice. I can't reproduce this, because I don't run LibreOffice 6.1 and before on any computer anymore. I've noticed this since LibreOffice 6.2.
Comment 1 Oliver Brinzing 2019-08-24 09:14:51 UTC
>The image gets in an infinite loop, LibreOffice freezes and CPU goes to 100%.

reproducible with:

Version: 6.2.6.2 (x64)
Build-ID: 684e730861356e74889dfe6dbddd3562aae2e6ad
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc:

Version: 6.3.0.4 (x64)
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: 

Version: 6.4.0.0.alpha0+ (x64)
Build ID: ec940941e0bd7db15c5cf7d43df82226e0d849dc
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

but *not* reproducible with:

LO 6.1.6.3
Comment 2 Oliver Brinzing 2019-08-24 09:17:13 UTC
Created attachment 153619 [details]
dotted lines example
Comment 3 Oliver Brinzing 2019-08-24 09:37:58 UTC
this issue seems OpenGL related: not reproducible with enabled OpenGL for me.

i noticed:
with a *fast* core i7 notebook and OpenGL disbabled:
screen update is slow, but will finish

with an old slow notebook (without OpenGL support):
screen update is slow, will not finish and restart again -> loop

seems to have started with:

https://gerrit.libreoffice.org/plugins/gitiles/core/+/313392119522c21a6ecd14403d6f92c948149df7

commit 313392119522c21a6ecd14403d6f92c948149df7	[log]
author	Armin Le Grand <Armin.Le.Grand@cib.de>	
Thu Oct 25 10:06:05 2018 +0200
committer	Armin Le Grand <Armin.Le.Grand@cib.de>
Thu Oct 25 12:43:55 2018 +0200
tree fbd1a112a41f83d34c6bb6ea79eeccf73dba3e7b
parent 8dec85a3b3f4cbd46b03f707458347a25cc22c15 [diff]

Reorganize FrameBorderPrimitive creation (II)

Step5: Move the view-dependent decomposition from
BorderLinePrimitive2D to SdrFrameBorderPrimitive2D.

$ git bisect bad e43ea17b239ce944089bdf02f43af32cf7f3feb6 is the first bad commit
commit e43ea17b239ce944089bdf02f43af32cf7f3feb6
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Thu Oct 25 04:30:39 2018 -0700

    source sha:313392119522c21a6ecd14403d6f92c948149df7
    source sha:313392119522c21a6ecd14403d6f92c948149df7

:040000 040000 4b77c1d56047d8d2fbc2b8aa95dacbdce0ee36e9 d06127464bfc9c703299dd1261a772e5c756afe6 M      instdir

/cygdrive/d/sources/bibisect/bibisect-win32-6.2
$ git bisect log
# bad: [35a87a66cfc6dfb661f6fed49fb32c081dd26bc7] source sha:d250c94d78ac7e79753aa30f869db919b01fc450
# good: [b0a56ec98b1368cb5e3e531e0b3f69565af91609] source sha:3a801799536e6870f2fb111b1cc00b9575a35a39
git bisect start 'master' 'oldest'
# good: [7f7b05d44d7d7f13cc9c865963a72e555b516b3d] source sha:1b88de0a07180661c4d5d6706247d546d06bc983
git bisect good 7f7b05d44d7d7f13cc9c865963a72e555b516b3d
# bad: [1c3155d561cb094926cd19aa514856dfb4e23c5e] source sha:a626bdd56d7116efa57e65403ad51b56657148c3
git bisect bad 1c3155d561cb094926cd19aa514856dfb4e23c5e
# good: [189df060b92de369d2cc8f0dba64ed5c53df7055] source sha:67e5201cc6caee52d8e37e98a0d535c085c19cb4
git bisect good 189df060b92de369d2cc8f0dba64ed5c53df7055
# good: [226d4eb9c28947a08cf78473d47bd7bf8c67bf5f] source sha:70198d4f7ffc7b3139cf34764b0e6bb6971489c6
git bisect good 226d4eb9c28947a08cf78473d47bd7bf8c67bf5f
# bad: [48f7f098ccf9ae592eade9bc77c903fff21d247c] source sha:094e7b6a1028620c2b1503de8b51dc6a2482e290
git bisect bad 48f7f098ccf9ae592eade9bc77c903fff21d247c
# good: [d3ee1ef07ed55a040171b2c161ce85d1f02666d4] source sha:9deabca91c8fd899fd162f4a16a1061793e8a10e
git bisect good d3ee1ef07ed55a040171b2c161ce85d1f02666d4
# good: [f8d019eb12c6f43aaea36b88ccec5d60ee64a4a8] source sha:199998361c3987f3bcdc26501b5f017d8965a22b
git bisect good f8d019eb12c6f43aaea36b88ccec5d60ee64a4a8
# good: [d1ff28e9504f94993095b1be770df84becf542e1] source sha:e82650dead9e1fe0f87c99495dd8b763a04080c8
git bisect good d1ff28e9504f94993095b1be770df84becf542e1
# good: [f51d86bfb1e84c8b729da5f39bf27d1614e6a9b5] source sha:8dec85a3b3f4cbd46b03f707458347a25cc22c15
git bisect good f51d86bfb1e84c8b729da5f39bf27d1614e6a9b5
# bad: [27dae5b7bb205df0c37a3aa69e41d4c201349f23] source sha:616554c36eec41f80424dd2a3c1e99d227b9eee6
git bisect bad 27dae5b7bb205df0c37a3aa69e41d4c201349f23
# bad: [865f20a8d154c5a0dec7ea57be6a2c68cffacfeb] source sha:ce155a8943bdd8cfa8e32e38fc83160df25beee1
git bisect bad 865f20a8d154c5a0dec7ea57be6a2c68cffacfeb
# bad: [dd676c61409f97c7e03271fae8f26b20b46c6b53] source sha:01679ba1373f1d1439d7bd5c350d48831a06ce84
git bisect bad dd676c61409f97c7e03271fae8f26b20b46c6b53
# bad: [e43ea17b239ce944089bdf02f43af32cf7f3feb6] source sha:313392119522c21a6ecd14403d6f92c948149df7
git bisect bad e43ea17b239ce944089bdf02f43af32cf7f3feb6
# first bad commit: [e43ea17b239ce944089bdf02f43af32cf7f3feb6] source sha:313392119522c21a6ecd14403d6f92c948149df7
Comment 4 Noel Grandin 2021-08-26 12:58:21 UTC
With current master, this seems pretty snappy