Bug 119366 - FREEZING with long and complex documents
Summary: FREEZING with long and complex documents
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, haveBacktrace, perf, regression
Depends on:
Blocks: CPU-AT-100% Writer-Table-Layouting
  Show dependency treegraph
 
Reported: 2018-08-19 17:40 UTC by gambacherkalbenstein
Modified: 2022-05-17 13:24 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
a selfmade german-oldnorse dictionary from an internet source (649.00 KB, application/vnd.oasis.opendocument.text)
2018-08-19 17:40 UTC, gambacherkalbenstein
Details
libre office freezing after going to page 4/220 (6.72 MB, video/mp4)
2018-08-19 18:25 UTC, BogdanB
Details
GDB trace of freeze with master (17.76 KB, text/plain)
2018-08-24 16:48 UTC, Buovjaga
Details
perf flamegraph (287.26 KB, application/x-bzip)
2019-09-23 17:53 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gambacherkalbenstein 2018-08-19 17:40:17 UTC
Created attachment 144306 [details]
a selfmade german-oldnorse dictionary from an internet source

when i am working with large and complex documents, writer usually freezes. it happens every time i am working with some documents, so writer nearly became usless for me.

this happens with virtually every little step, like deleting a letter.

it just recently happened - in a different document - that i wanted to delete all "sections" of a document an froze again
Comment 1 BogdanB 2018-08-19 18:25:15 UTC
Created attachment 144308 [details]
libre office freezing after going to page 4/220

See the video I made with 6.1 freezing just when at page 4/220. Not changeing anything...

Version: 6.1.1.0.0+
Build ID: 5a56b72413d5f555c854e36d3bd2fd50ec21644c
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-6-1, Time: 2018-08-15_02:45:13
Locale: ro-RO (ro_RO.UTF-8); Calc: group threaded
Comment 2 Jean-Baptiste Faure 2018-08-21 09:22:09 UTC Comment hidden (obsolete)
Comment 3 Telesto 2018-08-21 09:47:18 UTC
Repro with
Version: 6.2.0.0.alpha0+
Build ID: 414ef6cb187dd3bbcc917dbedf3c0c1cc8668f60
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-08-20_22:43:18
Locale: nl-NL (nl_NL); Calc: CL

it's initially working better with
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL

However eventually it will hang (consuming all resources) after a minute or so

No repro with as far I can tell (except with the spell checker enabled)
Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)
Comment 4 Telesto 2018-08-22 10:10:29 UTC
This should be bibisectable (with spell-checker disabled) assuming:
* my comment 3 about 4.0.0.3 is right 
* and with Linux also affected
Comment 5 Xisco Faulí 2018-08-22 13:19:16 UTC
I tried 3 times to bisect this issue but the results weren't correct...
If someone wants to try, I tried with bibisect-50max cleaning the user profile every time with rm -rf opt/user/.
I followed these steps:
1. Load the document
2. Wait until the word count reaches ~250.000.
3. Scroll down with the page down key...
Comment 6 BogdanB 2018-08-22 20:45:32 UTC Comment hidden (obsolete)
Comment 7 Buovjaga 2018-08-23 07:31:34 UTC Comment hidden (obsolete)
Comment 8 Telesto 2018-08-23 08:55:34 UTC
(In reply to Buovjaga from comment #7)
> (In reply to BogdanB from comment #6)
> > I bibisect with 5.4. Every instances went wrong!...
> 
> But that was known already :) Like Xisco said, the bibisecting should be
> attempted with bibisect-50max

Not totally convinced about the 50max repro (but surely no need to check 5.4). I could reproduce the issue with "oldest" in bibisect-50max. By scrolling up & down the document randomly.. (last page, first page etc)

It's a nasty bug to bibisected, because it's harder to trigger the "layout loop" with older version.
Comment 9 Buovjaga 2018-08-24 16:48:10 UTC
Created attachment 144415 [details]
GDB trace of freeze with master

It got stuck upon opening with gdb. Killed process and this is the result.

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: d30e76eb7854e9a4f170677719ad0ac3f92ef297
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; 
Locale: fi-FI (fi_FI.UTF-8); Calc: threaded
Built on August 23rd 2018
Comment 10 QA Administrators 2019-09-02 09:21:13 UTC Comment hidden (obsolete)
Comment 11 Jean-Baptiste Faure 2019-09-07 20:47:04 UTC
Still reproducible with LO 6.3.3.0+ and current master, both built at home under Ubuntu 18.04 x86-64

Best regards. JBF
Comment 12 Xisco Faulí 2019-09-23 15:27:15 UTC Comment hidden (obsolete)
Comment 13 Julien Nabet 2019-09-23 17:53:20 UTC
Created attachment 154393 [details]
perf flamegraph

Here's a Flamegraph from master sources updated today (203865e128ddea66041bb1597333dfb04ec81186)
Comment 14 Julien Nabet 2019-09-23 17:55:47 UTC
Michael: thought you might be interested in this one since Flamegraph shows that LO spends a lot of time in layout part (PrepareMake, MakeAll, etc).
Comment 15 QA Administrators 2022-04-20 03:36:45 UTC Comment hidden (obsolete)
Comment 16 Gabor Kelemen (allotropia) 2022-05-17 13:24:35 UTC
Still an issue in

Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 817b8fe7001a83cb74910eb09b7c14a3b95b8a39
CPU threads: 14; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: de-DE (hu_HU); UI: en-US
Calc: threaded

Document contains 2 tables that span all 220 pages.