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: 6.1.0.0.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) tree ebf199f2a5518452cdbc7354a6d04cd513911aed 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. ] Change-Id: Ib7fc1de55316a73188c023665a585ac7056341f7 Reviewed-on: https://gerrit.libreoffice.org/42447 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?
No repro Version: 6.3.0.0.alpha0+ 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 Calc: CL Opens fine, able to edit
In Version: 6.3.0.0.alpha1+ 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 Calc: threaded it takes real 0m13,461s user 0m12,644s sys 0m0,305s 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