Bug 138124 - FILEOPEN: MSO DOCX with image in footnote crashes and uses up 100% memory
Summary: FILEOPEN: MSO DOCX with image in footnote crashes and uses up 100% memory
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks: DOCX-Images
  Show dependency treegraph
 
Reported: 2020-11-11 07:37 UTC by Mike
Modified: 2020-11-13 08:22 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
DOCX crashes Writer on opening (15.71 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-11-11 07:38 UTC, Mike
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike 2020-11-11 07:37:44 UTC
Description:
Opening this DOCX in Writer causes LibreOffice to freeze, and it appears to use up all available memory in Windows Task Manager.

Removing the image from the footnote appears to resolve the crash.

Steps to Reproduce:
1. Open the DOCX
2. Observe LibreOffice responsiveness and memory usage

Actual Results:
LibreOffice becomes non-responsive and all system memory is consumed.

Expected Results:
Open the document, or at least, prevent all system memory from being used up.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Reproduced in 3.3.0 and 7.0.3.1.

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

Version: 7.0.3.1 (x64)
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-AU (en_AU); UI: en-GB
Calc: threaded
Comment 1 Mike 2020-11-11 07:38:42 UTC
Created attachment 167186 [details]
DOCX crashes Writer on opening
Comment 2 NISZ LibreOffice Team 2020-11-11 09:13:50 UTC
Reproduced with:

Version: 7.1.0.0.alpha1+ (x64)
Build ID: 00e5c63c35307faacf76a5e2ca7953c4208244ed
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL

But it was good in:
Version: 6.0.0.3
Build ID: 64a0f66915f38c6217de274f0aa8e15618924765
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: en-US (hu_HU); Calc: CL

and back to 5.1. 5.0 and before did not show the image in footnote.

6.1 started to exhibit the memory exhaustion problem.
Comment 3 Timur 2020-11-11 14:15:36 UTC
commit f804b37b9e989e31847306f4c0f742a3ded58a81
Date:   Thu Mar 29 14:53:39 2018 +0200
    source sha:3138abfb052a4241cfca4b8d430c139cca50a85c
    previous source sha:6c57ae39d783ae92a43dc2e113ea6e2dfb52af22

author	Justin Luth <justin_luth@sil.org>	2018-03-26 19:07:18 +0300
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2018-03-29 14:39:48 +0200
commit	3138abfb052a4241cfca4b8d430c139cca50a85c (patch)
tree	c9b55ae06c28c3fc5e097a9e224eca6e4f85acdd
parent	6c57ae39d783ae92a43dc2e113ea6e2dfb52af22 (diff)
tdf#112886 ooxmlimport: skip useless footnote placeholder

Justin, please take a look. 

Note: for those bibisects is useful 'timeout' to limit memory or time.
Comment 4 Xisco Faulí 2020-11-12 13:30:47 UTC
(In reply to Timur from comment #3)
> commit f804b37b9e989e31847306f4c0f742a3ded58a81
> Date:   Thu Mar 29 14:53:39 2018 +0200
>     source sha:3138abfb052a4241cfca4b8d430c139cca50a85c
>     previous source sha:6c57ae39d783ae92a43dc2e113ea6e2dfb52af22
> 
> author	Justin Luth <justin_luth@sil.org>	2018-03-26 19:07:18 +0300
> committer	Miklos Vajna <vmiklos@collabora.co.uk>	2018-03-29 14:39:48 +0200
> commit	3138abfb052a4241cfca4b8d430c139cca50a85c (patch)
> tree	c9b55ae06c28c3fc5e097a9e224eca6e4f85acdd
> parent	6c57ae39d783ae92a43dc2e113ea6e2dfb52af22 (diff)
> tdf#112886 ooxmlimport: skip useless footnote placeholder
> 
> Justin, please take a look. 
> 
> Note: for those bibisects is useful 'timeout' to limit memory or time.

The bisection doesn't make sense, the code removed in that commit was reintroduced in https://cgit.freedesktop.org/libreoffice/core/commit/?id=a991ad93dcd6807d0eacd11a50c2ae43a2cfb882
Comment 5 Xisco Faulí 2020-11-12 13:38:45 UTC
OTOH, I do confirm the bisection with bibisect-linux64-6.1 points to 3138abfb052a4241cfca4b8d430c139cca50a85c. Super weird...
Comment 6 Xisco Faulí 2020-11-12 13:42:21 UTC
it looks similar to bug 131651
Comment 7 Justin L 2020-11-13 07:07:57 UTC
Not sure what to think about this. It almost has to have exposed an existing potential problem. The difference between 6.0 and now after jmux's adding the stuff back in is that he exits from utext -> lcl_utext almost right away, while before it processed the function to the end (and supposedly effectively did nothing). But removing jmux's "return" and letting it process all the way through doesn't "fix" the problem now.

The fact that this is a footnote problem is too much to just be coincidence, so I believe the bisect and this must be a decent starting point, but I'm pretty sure that there is nothing wrong with the commit itself.
Comment 8 Justin L 2020-11-13 08:22:21 UTC
Round-tripping "image in footer.docx" in Word 2016 does not help.
However, changing the page size did "fix" the problem.

I tried adding text after the image in the footnote - that didn't help.
If I add some text before the footnote, it usually seems to help.

I ran perf record -g --pid=`pidof soffice.bin`
for the very first time, so I don't know what I am looking at. But it looks to me like this is getting hung up in layout.  Well, that kinda makes sense of the evidence. This particular document must just be hitting a weird layout situation.