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
Created attachment 167186 [details] DOCX crashes Writer on opening
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.
commit f804b37b9e989e31847306f4c0f742a3ded58a81 Date: Thu Mar 29 14:53:39 2018 +0200 source 3138abfb052a4241cfca4b8d430c139cca50a85c previous source 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.
(In reply to Timur from comment #3) > commit f804b37b9e989e31847306f4c0f742a3ded58a81 > Date: Thu Mar 29 14:53:39 2018 +0200 > source 3138abfb052a4241cfca4b8d430c139cca50a85c > previous source 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
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.
So: this is not a regression, not perf, and not related to DOCX :) And not about footer BTW - the image is in footnote :D How to repro from scratch: 1. In a new Writer document, insert a footnote. 2. Draw a thin rectangle there in the footnote area. 3. Open the rectangle position and size properties, set anchor to "as character", and width to a large enough value (on A4 page with default margins, 17 cm is enough, because that's the width of the text area, and so the rectangle can't fit on the same line with the footnote number). This OOM'd already in 6.0; but it may seem a regression, because this sequence worked without OOM in 5.0 (even though the output was unexpected there, with multiple empty "1" footnote lines above the final line with the rectangle). The change that turned the strange output into an OOM was commit 49f453755b72654ba454acc321210e8b040df714 (tdf#89714 - enable Widow/Orphan in default style, 2015-11-12). And yes, the difference between 5.0 and 5.1 was the orphan control property of the footnote paragraph. Enabling the paragraph's orphan control in the steps shown above makes Writer hang/OOM even in OOo 2.2.0. Inserting a space between the footnote number and the wide object fixes it all. Presumably, the layout problem is rooted in some inability to split the number portion from the rest (without an explicit break opportunity).
Created attachment 186635 [details] Minimal reproducer
Created attachment 186636 [details] Without orphan control This would show the abnormal repeated footnote lines
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/46cf6d3f899fbab7524085597483feeb6f5d6cd9 tdf#138124: do not reset IsFootnoteDone status in line layout It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/16fca224a398b562d009fb562493fd5460bb3dc5 tdf#138124: do not reset IsFootnoteDone status in line layout It will be available in 7.5.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-5-3": https://git.libreoffice.org/core/commit/c950f16a2bfec74b757bb32bc869b01faee6dac1 tdf#138124: do not reset IsFootnoteDone status in line layout It will be available in 7.5.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.