Bug 76385 - loop opening particular .docx with large table nested tables across pages (comment 5)
Summary: loop opening particular .docx with large table nested tables across pages (co...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) Master
Hardware: All All
: high major
Assignee: Not Assigned
Keywords: filter:docx, haveBacktrace, perf
Depends on:
Blocks: DOCX-Opening
  Show dependency treegraph
Reported: 2014-03-20 08:29 UTC by Sourav
Modified: 2023-04-26 12:57 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Original File (36.16 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-03-20 08:51 UTC, Sourav
typescript with backtrace with symbols (56.37 KB, text/plain)
2014-03-20 17:05 UTC, Terrence Enger
console logs + bt with debug symbols (master sources) (53.49 KB, text/plain)
2015-04-07 21:04 UTC, Julien Nabet
Flamegraph (332.10 KB, application/x-bzip)
2023-04-26 12:57 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description Sourav 2014-03-20 08:29:19 UTC
1)Launch LO.
2)Import the attached file.

LO crashes
Comment 1 Sourav 2014-03-20 08:51:45 UTC
Created attachment 96083 [details]
Original File
Comment 2 Terrence Enger 2014-03-20 17:02:49 UTC
Opening the attached file from the command line, my LibreOffice produces a segmentation fault.  I am setting status NEW.

Original summary said Windows, so I am leaving platform All.

My LibreOffice is master commit 806f4d8, fetched 2014-03-04, configured:
built and running on debian-wheezy.
Comment 3 Terrence Enger 2014-03-20 17:05:13 UTC
Created attachment 96114 [details]
typescript with backtrace with symbols

For the benefit of bugzilla search:

#0  0x00007fad6b1733f8 in __dynamic_cast () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

#1  0x00007fad49df9129 in lcl_InnerCalcLayout (pFrm=0x26e4b40, nBottom=25107, _bOnlyRowsAndCells=false) at /home/terry/lo_hacking/git/libo4/sw/source/core/layout/tabfrm.cxx:1486
Comment 4 Julien Nabet 2015-04-07 21:04:34 UTC
Created attachment 114680 [details]
console logs + bt with debug symbols (master sources)

Just to give an updated bt since I can still reproduce the crash with master sources updated today.
Comment 5 Xisco Faulí 2015-08-24 14:54:34 UTC
I can no longer reproduce the crash with

Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Locale: es-ES (es_ES)

on Windows 7 (64-bit)

However, it took around 50 seconds to open the document, so there's still a performance issue present.
Comment 6 Terrence Enger 2015-08-24 21:51:38 UTC
With dbgutil version 2015-08-24 running in a chroot environment to
debina-sid, the program pegged the CPU for an hour and filled the
terminal buffer with messages (line breaks added) ...

        <SwFlowFrm::MoveBwd(..)> - layout loop control for layout
        action <Move Backward> applied!

In the bug summary, I am changing "segfault" to "loop".
Comment 7 Julien Nabet 2015-08-31 19:06:03 UTC
Comment on attachment 114680 [details]
console logs + bt with debug symbols (master sources)

On pc Debian x86-64 with master sources, I got a loop too but no crash
Comment 8 Robinson Tryon (qubit) 2015-12-09 18:08:22 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2018-05-31 02:52:28 UTC Comment hidden (obsolete)
Comment 10 Terrence Enger 2018-06-14 01:01:44 UTC
I still see the bug in daily Linux dbgutil bibisec repository version
2018-06-13 running on debian-buster.

In particular, LO displayed the first page of the document in under a
minute, but the screen is still unresponsive and LibreOffice is stil
using ~ 100% CPU after 88 CPU minutes.
Comment 11 Buovjaga 2019-03-28 08:10:54 UTC
Still sluggish looping.

Arch Linux 64-bit
Build ID: 9c5d33e3c9e4a680af61a9e7af8fa73d08b33834
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 28 March 2019
Comment 12 QA Administrators 2021-03-28 03:36:31 UTC Comment hidden (obsolete)
Comment 13 Terrence Enger 2021-03-28 17:33:57 UTC
Opening the attached file in a local --dbgutil build of commit
feb6fd1f (2021-03-17), built an running on debian-buster, I see:

(*) The Writer window quickly shows the top of the document.

(*) It is possible to page up and down throught the nine pages of the
document with some niticeable delays.

(*) CPU usage drops after about 1 min 41 seconds CPU.

I think this should qualify for RESOLVED WORKSFORME, but I shall wait
for Sourav to comment.
Comment 14 Buovjaga 2021-03-28 21:06:41 UTC
I tried with the latest in Linux 7.2 bibisect repo and the CPU usage won't drop even after several minutes.

Note that in general, you should not test performance issues with debug/dbgutil builds, because they include various functionality that affects performance.
Comment 15 Terrence Enger 2021-03-29 22:57:43 UTC

I understand that --enable-dbgutil can cause poorer performance.  Is
there any way that it can causes better performance?  Anyway, I take
the loop to be not merely a question of peformance.

Meanwhile, all I get is loops, even when I go back and rebuild the
version which I reported to open the file successfully.  Sigh!
Comment 16 Buovjaga 2021-03-30 09:08:49 UTC
(In reply to Terrence Enger from comment #15)
> I understand that --enable-dbgutil can cause poorer performance.  Is
> there any way that it can causes better performance?

I have not heard of such cases
Comment 17 Roman Kuznetsov 2023-04-26 10:40:08 UTC
30 sec for opening and full processing in

Version: (X86_64) / LibreOffice Community
Build ID: 0ee9501c0b7dc1a291715fff9c1934b1c08cb654
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: threaded
Comment 18 Julien Nabet 2023-04-26 12:57:03 UTC
Created attachment 186936 [details]

On pc Debian x86-64 with master sources updated today + gen rendering, the file opened quite quickly so I also scrolled until the end of the file and retrieved a Flamegraph.