Created attachment 125982 [details]
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
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
Please change to critical because possibility of exploitation after LO runs out of memory and crash.
(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).
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
(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.
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.
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.
Why did you add "security"?
Because I am almost sure the bug is exploitable
Removing security keywords per dev comments on IRC.
Shouldn't this be a target: ?
(In reply to ekari from comment #11)
> Shouldn't this be a target: ?
"Generally “target” is automatically entered when a developer commits a patch specifically to fix a bug reported on the bug tracker. Users, QA and Developer should generally not manually enter “target” into whiteboard"
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.
confirmed with bibisect41max. Document first opens after:
Author: Fridrich Štrba <email@example.com>
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.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
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.
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)
Looks like anchoring issue to me. Change the anchor for the heading and problem is gone
Still repro with:
Version: 22.214.171.124.alpha0+ (x64) / LibreOffice Community
Build ID: cb2827f5f65324f309fa0e3c30d0b19ad237410e
CPU threads: 16; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
This seems to be the same issue as bug 38575
*** This bug has been marked as a duplicate of bug 38575 ***