Bug 117701 - FILEOPEN DOCX causes libreoffice to hang and use all available RAM & swap, cripples system
Summary: FILEOPEN DOCX causes libreoffice to hang and use all available RAM & swap, cr...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.2.1 release
Hardware: x86-64 (AMD64) All
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: Performance CPU-AT-100%
  Show dependency treegraph
 
Reported: 2018-05-19 04:22 UTC by g4827387
Modified: 2024-04-25 06:39 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


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? (697.33 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-05-19 04:22 UTC, g4827387
Details

Note You need to log in before you can comment on or make changes to this bug.
Description g4827387 2018-05-19 04:22:16 UTC
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
Comment 1 raal 2018-05-19 05:26:54 UTC
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.
Comment 2 raal 2018-05-19 05:29:23 UTC
I can open the file in LO 4.1 without problems,regression
Comment 3 Julien Nabet 2018-05-19 15:38:48 UTC
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.
Comment 4 Julien Nabet 2018-05-19 15:41:33 UTC
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.
Comment 5 Buovjaga 2018-06-06 18:46:10 UTC
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
Comment 6 Miklos Vajna 2019-05-14 14:08:20 UTC
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?
Comment 7 Telesto 2019-05-14 14:19:39 UTC
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
Comment 8 Xisco Faulí 2019-05-14 14:20:25 UTC
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
Comment 10 Miklos Vajna 2019-05-14 14:43:14 UTC
Thanks Xisco, I just came to the same conclusion. :-)
Comment 11 Xisco Faulí 2019-05-14 14:54:59 UTC
(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