| Summary: | FILEOPEN DOCX causes libreoffice to hang and use all available RAM & swap, cripples system | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | g4827387 |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | VERIFIED FIXED | ||
| Severity: | critical | CC: | ilmari.lauhakangas, jluth, raal, serval2412, telesto, vmiklos, xiscofauli |
| Priority: | high | Keywords: | bibisected, bisected, filter:docx, regression |
| Version: | 6.0.2.1 release | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | All | ||
| See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=121670 https://bugs.documentfoundation.org/show_bug.cgi?id=123435 |
||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 136524, 113510 | ||
| Attachments: | 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? | ||
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 |
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