Created attachment 62540 [details] EPS file to reproduce the problem This is a regression that appeared between LibreOffice 3.4.5.2 in Fedora 16 and LibreOffice 3.5.4.2 in Fedora 17. I'm currently writing a document containing about 7 encapsulated PostScript images (.eps). LO has always been slow to open, render and save this document, but it was stable. With the version I have, Writer starts using about 2GB in less than one hour of work, merely typing text around an image. Attached is an EPS file you can insert a few times if you want to reproduce the bug.
Created attachment 63060 [details] Text document to easily reproduce the leak OK, took me some work, but I managed to find out the root cause of the bug. It's not EPS images in general, it's *cropped* EPS (and maybe others) images. With the attached document, you can reproduce this at will with 3.6.0beta1 . You just have to insert a handful of line breaks and/or page breaks somewhere in the beginning of the text, and it will somehow invalidate the thumbnails that were previously created for the pictures. Then, just scroll down the doc, and you will see the memory and CPU use raise, and Writer hang for a few second. It really looks like changing the layout in some way acts like opening the document from scratch again, except that previously used memory is not freed.
I did not observe unexpected things with reporter's text kit and with Server Installation of "LibreOffice 3.6.0.0.beta2 German UI/Locale [Build-ID: f010139] on German WIN7 Home Premium (64bit)
Might be a memory leak. PS: How to confirm a memory leak @ Rainer in German: Ein Memory-leak ist einfach, dass Arbeitsspeicher bis zum Beenden (und eventuall auch danach nicht freigegeben wird....
Confirmed on Linux Ubuntu LTS 12.04 amd64 LibreOffice 3.5.7.2. The more one works with the document (scrolling up/down, inserting, deleting), the more memory allocated to LibreOffice increases. Solution (temporary): save, close and reopen your file This bug may be related to: Bug 41407 - EDITING: Presentation documents with a large number of complex EPS graphics renders very slowly.
This relates to bug #37837 but can not be described as duplicate since "This is a regression that appeared between LibreOffice 3.4.5.2 in Fedora 16 and LibreOffice 3.5.4.2 in Fedora 17." What I do notice when opening attachment https://bugs.freedesktop.org/attachment.cgi?id=63060 is that while loading the file, 'gs' and 'convert' are executed periodically one after. I'm suspecting that both tools are executed for each rendered EPS while using either should be sufficient. Tested on Debian 7 32-bit, LO 4.1.0.4.
Created attachment 98083 [details] Valgrind On pc Debian x86-64 with master sources updated today, I retrieved a Valgrind trace with this command line: valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./soffice.bin --splash-pipe=0 ~/compile-libreoffice/bugs/50697_eps_memoryleak/test.odt >& /tmp/valgrind.log
Caolán: Valgrind traces show some lost blocks from vcl. Are there parts which may help in it?
caolanm->julien: valgrind's memleak report there which has big OutputDevice::OutputDevice allocated hunks was a master-only recent regression from cf3c6cb40f99fa1761a6af3d7447a899b9447868 which should be fixed now
Thank you Caolán for your feedback. Do you think it'd be useful I get a new Valgrind trace, more generally, is there still some memleak here? (also considering your last patch about EPS)
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b25871da62facc20387ebfa2b908422578ca8ce9 fix crash found when exploring fdo#50697 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=62b0eaf37c08dd27244e77b8bc90c691b000ebd6 Related: fdo#50697 reset the cache timeout on GetGraphic The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
caolanm->julien: I'm not entirely sure if there is still a leak here. It is definitely absoletely dog slow, especially on the debug version, my efforts here at least stop the images getting swapped out so frequently which helps a little. But its the super slow re-draw of them that is the big slowdown. On the leak side of things the document doesn't *seem* to massively increase size for me over time. It just jump up as the images are swapped in, but jumps down again after the 50secs or so timeout. I'd be reluctant to call it fixed. Another valgrind leak trace doesn't hurt anyway. Though we might have one of the problems where we're not technically leaking because we explicitly delete on exit but are practically leaking in not releasing when we should have earlier.
Created attachment 98191 [details] new Valgrind trace Build made from master sources git updated today ( 1e5b495a882493a81cc82ee34e3339b071bc162d) Valgrind version: 3.9.0-5 gcc (Debian 4.8.2-16) 4.8.2
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8ff260e47873674ca03a334f6b3198d66dc68db7&h=libreoffice-4-2 fix crash found when exploring fdo#50697 It will be available in LibreOffice 4.2.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
On pc Debian x86-64 with master sources updated today, I don't have anything in Valgrind. Milan: for the test, could you give a try to master daily build? (see http://dev-builds.libreoffice.org/daily/master/)
Looks like it's been fixed in 4.3.4.1 on Fedora 20, AFAICT from the reproducer I posted here (I no longer use EPS images -- I've moved to SVGs since I hit this bug). Thanks!
Thank you Milan for your feedback! Just nitpicking, since there's no specific fix, let's put this to WFM.