Created attachment 142198 [details]
WARNING! reliably to cause libreoffice to increase ram usage till system is RAM&swap starved, ?would it be prudent to ready a means to kill libreoffice before that happens?
it is a pdf document that had pages edited in inkscape (maybe 0.92)
then re-integrated using pdfshuffler (0.6.0)
then converted to a ms-word document using ms-word 2013's pdf-import-feature
and was then edited before opened using libreoffice
prob not technical enough to debug unless shown how
I can confirm with Version: 220.127.116.11.alpha1+
Build ID: 44a468323f3f011c41f892117f418987f9c98477
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2;
After opening the file, LO runs at 100% CPU and RAM goes up. LO not react. I can open the file in word 2010 without problems.
I can open the file in LO 4.1 without problems,regression
On pc Debian x86-64 with master sources updated today +gtk3 + enable-dbgutil, it takes some time (about 30 secs on i5, 6GB) but it opens.
Argh, file opens but then LO seems stuck.
I noticed this on console:
warn:legacy.osl:5018:5018:sw/source/core/layout/calcmove.cxx:1734: +TextFrame didn't respect WouldFit promise.
Bibisected with Win 6.0 repo to https://cgit.freedesktop.org/libreoffice/core/commit/?id=c72a1a74b5b1064fc9cdf9994b11fce26d866e26
commit c72a1a74b5b1064fc9cdf9994b11fce26d866e26 (patch)
parent f00ca5f26492a56378da0c7e54003419d8c7dd05 (diff)
Related: tdf#112211 DOCX import: fix handling of missing first ind in <w:lvl>
Usually a DOCX numbering definition has multiple levels, each level
containing a <w:ind ... w:hanging="..."/> element. When this is missing,
we should default to the Word default, not to the Writer one.
This makes the DOCX version of tdf#106953 imported correctly, in
preparation of dropping the original fix that helped RTF only.
[ The DOC version of the bugdoc is still not imported correctly. ]
Seems legit, so
Adding Cc: to Miklos Vajna
I tried to reproduce this with core.git master 89fd86540580ebbc269848b3c4b6539e070829a0 (latest as of yesterday) and the document loaded for me. It's a bit slow, but it's of ~140 pages.
Can you still reproduce this?
Build ID: 91b2239783dc716bd71ce7962bfd7e341dfe4175
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win;
TinderBox: Win-x86@42, Branch:master, Time: 2019-05-08_09:49:32
Locale: nl-NL (nl_NL); UI-Language: en-US
Opens fine, able to edit
Build ID: 5053584e71d98ae6bfba405145c45815ba7ad898
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
and then it nicely scrolls. OTOH, I see the pages are black now ( but that is another issue )
Closing as RESOLVED WORKSFORME. I'll bisect when it got fixed
Fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=14087d3e5fed9b56384432d9aeac608a5e8d86cf
Thanks Xisco, I just came to the same conclusion. :-)
(In reply to Xisco Faulí from comment #8)
> and then it nicely scrolls. OTOH, I see the pages are black now ( but that
> is another issue )
Already reported in bug 123435