Bug 50697 - EDITING: terrible memory leak with documents containing cropped PostScript (.eps) images
Summary: EDITING: terrible memory leak with documents containing cropped PostScript (....
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.0.0.beta1
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:4.3.0 target:4.2.5
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-04 14:03 UTC by Milan Bouchet-Valat
Modified: 2015-01-04 12:43 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
EPS file to reproduce the problem (5.27 KB, application/postscript)
2012-06-04 14:03 UTC, Milan Bouchet-Valat
Details
Text document to easily reproduce the leak (33.66 KB, application/vnd.oasis.opendocument.text)
2012-06-15 01:48 UTC, Milan Bouchet-Valat
Details
Valgrind (436.47 KB, application/x-bzip)
2014-04-27 16:48 UTC, Julien Nabet
Details
new Valgrind trace (427.96 KB, application/x-bzip)
2014-04-29 19:34 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Bouchet-Valat 2012-06-04 14:03:31 UTC
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.
Comment 1 Milan Bouchet-Valat 2012-06-15 01:48:55 UTC
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.
Comment 2 Rainer Bielefeld Retired 2012-06-27 21:57:29 UTC
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)
Comment 3 Florian Reisinger 2012-07-06 08:03:56 UTC
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....
Comment 4 Emmanuel 2013-05-30 10:21:17 UTC
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.
Comment 5 Björgvin Ragnarsson 2013-09-20 01:33:52 UTC
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.
Comment 6 Julien Nabet 2014-04-27 16:48:52 UTC
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
Comment 7 Julien Nabet 2014-04-27 16:50:31 UTC
Caolán: Valgrind traces show some lost blocks from vcl. Are there parts which may help in it?
Comment 8 Caolán McNamara 2014-04-29 11:20:32 UTC
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
Comment 9 Julien Nabet 2014-04-29 13:07:41 UTC
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)
Comment 10 Commit Notification 2014-04-29 14:25:16 UTC
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.
Comment 11 Commit Notification 2014-04-29 14:25:30 UTC
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.
Comment 12 Caolán McNamara 2014-04-29 15:13:44 UTC
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.
Comment 13 Julien Nabet 2014-04-29 19:34:43 UTC
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
Comment 14 Commit Notification 2014-05-03 06:42:09 UTC
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.
Comment 15 Julien Nabet 2015-01-03 22:47:01 UTC
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/)
Comment 16 Milan Bouchet-Valat 2015-01-04 12:42:18 UTC
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!
Comment 17 Julien Nabet 2015-01-04 12:43:56 UTC
Thank you Milan for your feedback!
Just nitpicking, since there's no specific fix, let's put this to WFM.