Bug 149505 - Writer slow to open/work with strange 107-pages DOCX where all content is in headers (also slow in MSO)
Summary: Writer slow to open/work with strange 107-pages DOCX where all content is in ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.3.2.2 release
Hardware: All Linux (All)
: lowest normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx, haveBacktrace, perf
Depends on:
Blocks: DOCX-Opening
  Show dependency treegraph
 
Reported: 2022-06-09 17:03 UTC by Rafael Lima
Modified: 2024-08-06 09:41 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
DOCX file where the problem occurs (30.92 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-06-09 17:03 UTC, Rafael Lima
Details
Screencast with gtk3 (20.15 MB, video/webm)
2022-06-16 10:34 UTC, Michael Weghorn
Details
Perf flamegraph of file opening (3.19 MB, image/svg+xml)
2024-08-06 09:41 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Lima 2022-06-09 17:03:00 UTC
Created attachment 180656 [details]
DOCX file where the problem occurs

Steps to reproduce:

1) Open attached file
2) Writer hangs and becomes unresponsive
3) Only way out is "killing" the process

Running LO from the terminal, after some time waiting for the document to open I start getting the following message multiple times:

warn:legacy.osl:51766:51766:sw/source/core/layout/layact.cxx:574: LoopControl_1 in SwLayAction::InternalAction


Repro with

Version: 7.4.0.0.alpha1+ / LibreOffice Community
Build ID: 118bafcfd1ce4a26ec9df912197ebd466d1bd497
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: CL

And also in LO 7.3

Version: 7.3.3.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.3~rc2-0ubuntu0.21.10.1~lo1
Calc: threaded
Comment 1 Dieter 2022-06-09 21:13:42 UTC
Can't confirm with

Version: 7.3.4.1 (x64) / LibreOffice Community
Build ID: 13668373362b52f6e3ebcaaecb031bd59a3ac66b
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL
Comment 2 raal 2022-06-11 04:29:47 UTC
No crash Version: 7.4.0.0.alpha1+ / LibreOffice Community
Build ID: d4123356c61db269651e950a0a2cc93e6d801c90
CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded Jumbo
Comment 3 Timur 2022-06-11 07:52:20 UTC Comment hidden (obsolete)
Comment 4 Rafael Lima 2022-06-16 01:38:33 UTC
(In reply to Timur from comment #3)
> Please try with GEN and GTK3 (profile reset is unlikely but also try).

I tried with the latest nightly build with a clean profile. The file initially hangs for 15 seconds before LibreOffice starts responding.

It's no longer a crash, but a hanging problem... it's taking longer than it should to open this file.

Also, it's not happening in "gen" and "gtk3", but only in "kf5".

System info

Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: cb83063cc0eb4e93bd44bc0cb9b7c4841230cdef
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: threaded
Comment 5 Timur 2022-06-16 10:27:53 UTC
I'll confirm like this: Writer longer opening a DOCX in kf5 and qt5, compared to gen, gtk3. Measured on 2nd open, it's 20 sec compared to 5 sec.
Comment 6 Michael Weghorn 2022-06-16 10:34:50 UTC
Created attachment 180795 [details]
Screencast with gtk3
Comment 7 Michael Weghorn 2022-06-16 10:36:35 UTC
Does working with the document actually behave as expected for you when using gtk3?

For me, while it's a faster to load with gtk3 as compared to kf5 and initially looks OK, LO starts "freezing" as I start "doing something" (typing a bit in the document, scrolling,...), s. screencast in attachment 180795 [details], created with a LO build from the bibisect repo:

Version: 7.4.0.0.alpha1+ / LibreOffice Community
Build ID: d4123356c61db269651e950a0a2cc93e6d801c90
CPU threads: 12; OS: Linux 5.18; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded


When using a debug build of current master (which is slower than a release build), it's much worse.

Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: 578521ed67ff905bcd2e1b56f0fee6a0635b41e7
CPU threads: 12; OS: Linux 5.18; UI render: default; VCL: gtk3
Locale: en-US (en_GB.UTF-8); UI: en-US
Calc: threaded

To me, it therefore looks more like a Writer problem with the attached doc than a problem specific to kf5 (even if it becomes more apparent there because overall experience is even worse there).
Comment 8 Timur 2022-06-16 12:41:29 UTC
Yes, work is slow in gtk3, actually open is also slow in GUI. 
Previously I used variable OOO_EXIT_POST_STARTUP which probably gives false results here.
As noted, no repro in Windows.
Comment 9 Timur 2022-06-16 12:54:03 UTC
MSO is also slow to open. This is "pathological document", all text is in headers!? Lowest priority if any.
Comment 10 Buovjaga 2024-07-02 17:00:13 UTC
Still repro

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: f457046fa40af781a518a4962571c1056a2c326d
CPU threads: 8; OS: Linux 6.9; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded
Comment 11 Buovjaga 2024-08-06 09:41:44 UTC
Created attachment 195733 [details]
Perf flamegraph of file opening

I did *not* use OOO_EXIT_POST_STARTUP=1 for this.

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ca466a4a01657e2dad61ca909bd6ab5188f8ccc9
CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded