Bug 100678 - FILEOPEN Endless pagination loop until resources are depleted
Summary: FILEOPEN Endless pagination loop until resources are depleted
Status: RESOLVED DUPLICATE of bug 38575
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:doc, notBibisectable, perf
Depends on:
Blocks: Anchor-and-Text-Wrap Layout-Loops, Writer-Loops DOC
  Show dependency treegraph
 
Reported: 2016-06-29 14:14 UTC by E.Mi
Modified: 2022-03-10 09:21 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
docm (267.38 KB, application/vnd.ms-word.document.macroEnabled.12)
2016-06-29 14:14 UTC, E.Mi
Details
homol_cart_simplified.docx: reduced to empty page followed by chart (120.53 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-01-08 10:46 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description E.Mi 2016-06-29 14:14:17 UTC
Created attachment 125982 [details]
docm
Comment 1 Buovjaga 2016-07-02 19:48:34 UTC
Yes, it goes into an infinite pagination loop (page count increases).
Like mentioned in summary, it causes unresponsiveness in the whole operating system, which is quite alarming.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: ef47ce2397d4ed453fe01d994d13a13f442ec3bb
CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8)
Built on July 2nd 2016
Comment 2 E.Mi 2016-07-03 11:16:26 UTC Comment hidden (obsolete)
Comment 3 Buovjaga 2016-07-03 19:08:21 UTC
(In reply to ekari from comment #2)
> Please change to critical because possibility of exploitation after LO runs
> out of memory and crash.

We have this guideline for priority and severity: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Critical is generally used for a severe problem that affects a large number of users (usually a regression).
Comment 4 E.Mi 2016-07-04 18:09:46 UTC
According to the image you provided I reaffirm this bug as a Highest/High critical bug. Bug causes crash? It will after memory is full --> Happen very frequently? No --> Does this bug affect a major component? I think yes --> Highest Critical
Comment 5 Buovjaga 2016-07-04 19:00:59 UTC
(In reply to ekari from comment #4)
> According to the image you provided I reaffirm this bug as a Highest/High
> critical bug. Bug causes crash? It will after memory is full --> Happen very
> frequently? No --> Does this bug affect a major component? I think yes -->
> Highest Critical

Does the bug involve .. inability to open particular documents: high/major.
Comment 6 E.Mi 2016-07-04 19:19:28 UTC
That's if you take a no route, "Does it cause a crash?" --> I think it should be yes because this will cause a crash when out of memory.
Comment 7 Julien Nabet 2016-07-04 20:15:12 UTC
On pc Debian x86-64 with LO Debian package 5.1.4 or with master sources updated today (with enable-dbgutil), I could reproduce the problem.

Michael: thought you might be interested in this one since it concerns Writer+may have some idea about how LO should react in case of lack of memory.
Comment 8 Buovjaga 2016-07-27 07:06:43 UTC Comment hidden (off-topic)
Comment 9 E.Mi 2016-07-27 07:39:38 UTC Comment hidden (off-topic)
Comment 10 Buovjaga 2016-07-27 09:07:50 UTC Comment hidden (off-topic)
Comment 11 E.Mi 2016-07-27 18:04:00 UTC Comment hidden (off-topic)
Comment 12 Buovjaga 2016-07-27 18:38:45 UTC Comment hidden (off-topic)
Comment 13 Justin L 2016-12-16 07:18:46 UTC
notBibisectable: using bibisect43all, the document fails to open between Mon Dec 3 18:04:24 2012 +0100 commit ce90f99a2d66c2b998ad3f9f028e2ea623a757f5 and Wed May 1 14:30:14 2013 +0100 commit 2b449f5f9ad126618ec85d442ec149c5864853de.  Just before LO4.0, it opened OK. In LO4.1, it looped endlessly.
Comment 14 Justin L 2016-12-16 08:04:40 UTC
confirmed with bibisect41max.  Document first opens after:
    commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=4314e6548356a5d2f1dc45e2aa501e37bd5a794e
    Author:     Fridrich Štrba <fridrich.strba@bluewin.ch>
    CommitDate: Thu May 2 12:58:06 2013 +0200
        Fix out-of-bonds Sequence access in NumberingManager with page numbering

This appears to be unrelated to the looping issue, but perhaps we can remove the page numbering from the sample document and isolate the behaviour of this reported bug.
Comment 15 QA Administrators 2017-12-17 03:29:40 UTC Comment hidden (obsolete, spam)
Comment 16 Justin L 2018-01-08 10:46:00 UTC
Created attachment 138952 [details]
homol_cart_simplified.docx: reduced to empty page followed by chart

Reconfirmed that there is no point in trying to bibisect this. Tried to simplify the document as much as possible to allow focus on the layout's endless looping bug, which keeps adding empty pages before the full-page chart.
Comment 17 QA Administrators 2019-01-14 03:52:04 UTC Comment hidden (obsolete)
Comment 18 Julien Nabet 2019-05-29 17:40:48 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this with different renderings (I used homol_cart...)

The most interesting one seems the kde5 one with:
#0  0x00007fffd083487d in SwLayAction::InternalAction(OutputDevice*) (this=0x7fffffff11a0, pRenderContext=0x55555b300e10) at /home/julien/lo/libreoffice/sw/source/core/layout/layact.cxx:628
#1  0x00007fffd083374d in SwLayAction::Action(OutputDevice*) (this=0x7fffffff11a0, pRenderContext=0x55555b300e10) at /home/julien/lo/libreoffice/sw/source/core/layout/layact.cxx:348
#2  0x00007fffd083ab3b in SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) (this=0x7fffffff1260, pRt=0x55555b336280, pI=0x55555b14a690) at /home/julien/lo/libreoffice/sw/source/core/layout/layact.cxx:2171
#3  0x00007fffd0de7ce8 in SwViewShell::LayoutIdle() (this=0x55555b347310) at /home/julien/lo/libreoffice/sw/source/core/view/viewsh.cxx:723
#4  0x00007fffd04776e3 in sw::DocumentTimerManager::DoIdleJobs(Timer*) (this=0x55555ae67650) at /home/julien/lo/libreoffice/sw/source/core/doc/DocumentTimerManager.cxx:178
#5  0x00007fffd0477561 in sw::DocumentTimerManager::LinkStubDoIdleJobs(void*, Timer*) (instance=0x55555ae67650, data=0x55555ae67668)
    at /home/julien/lo/libreoffice/sw/source/core/doc/DocumentTimerManager.cxx:158
Comment 19 Telesto 2020-05-24 08:10:40 UTC
Looks like anchoring issue to me. Change the anchor for the heading and problem is gone
Comment 20 Telesto 2020-05-24 08:10:40 UTC Comment hidden (obsolete)
Comment 21 Katka 2021-08-08 20:35:40 UTC
Still repro with:
Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: cb2827f5f65324f309fa0e3c30d0b19ad237410e
CPU threads: 16; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Comment 22 Xisco Faulí 2022-03-10 09:21:07 UTC
This seems to be the same issue as bug 38575

*** This bug has been marked as a duplicate of bug 38575 ***