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
LibreOffice becomes non-responsive and all system memory is consumed.
Open the document, or at least, prevent all system memory from being used up.
User Profile Reset: Yes
Reproduced in 3.3.0 and 220.127.116.11.
Version: 18.104.22.168 (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
Created attachment 167186 [details]
DOCX crashes Writer on opening
Version: 22.214.171.124.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
But it was good in:
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.
Date: Thu Mar 29 14:53:39 2018 +0200
previous source sha:6c57ae39d783ae92a43dc2e113ea6e2dfb52af22
author Justin Luth <firstname.lastname@example.org> 2018-03-26 19:07:18 +0300
committer Miklos Vajna <email@example.com> 2018-03-29 14:39:48 +0200
commit 3138abfb052a4241cfca4b8d430c139cca50a85c (patch)
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.
(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 <firstname.lastname@example.org> 2018-03-26 19:07:18 +0300
> committer Miklos Vajna <email@example.com> 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
OTOH, I do confirm the bisection with bibisect-linux64-6.1 points to 3138abfb052a4241cfca4b8d430c139cca50a85c. Super weird...
it looks similar to bug 131651
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.
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.