memory leak in evince?

[Stephen Cradock]

Binary package hint: evince

I'm running Gutsy, all up to date, and finding evince very slow and erratic with large (100s of pages, 30-50MB) PDF files.

Machine triple-boots Feisty/Gutsy/WinXP; HP Pavilion with 512 MB RAM, Athlon 64 3200+ single processor.

In Feisty evince loads large PDFs fine, changes pages smoothly. System Monitor shows evince process uses 50-100MB with a 50MB file open and static; this bounces up by another 2 to 50 MB when I change to a new page, but then drops back to the same level as before.

In Gutsy (2.6.22-9-generic kernel) same file loads more slowly, system freezes for ages before recovering. System Monitor shows evince using 250 or more MB when the 50MB file is open and static, bouncing up to 350-400 MB when I change to another page. Then the memory usage stay high (~100%) for much longer, probably until some is paged out to swap. The effect is that the system has no (or very little) free user memory most of the time, which makes it very hard to use ......

Acrobat reader in WinXP behaves much more like Feisty/evince, though the % memory used rises slowly as more pages are added to the "looked at" stack. It never jumps to anywhere near 100%.

Both Ubuntu installs use the same swap partition, 1.4 GB; both actually use it, according to System Monitor.

[Sebastien Bacher (seb128)]

Thank you for your bug. What videocard and driver do you use? Could be a duplicate of bug #122786

[Stephen Cradock (s-cradock)]

Thanks for the response. I have an ATI Radeon Express 200M 5955 card, and I'm using the latest fglrx driver in Gutsy. Restricted Drivers Manager downloaded and installed it automatically for me after the last kernel upgrade - much less hassle than in Feisty. I use the restricted driver because I like GoogleEarth, which hangs on initialize with the Mesa driver (or the wrong ATI driver, for that matter).If that could be the problem, I'll try going back to the Mesa driver and see if it eliminates the evince glitch. I'll let you know.Stephen Cradock> From: <email address hidden>> To: <email address hidden>> Date: Mon, 20 Aug 2007 22:25:42 +0000> Subject: [Bug 132612] Re: memory leak in evince?> > Thank you for your bug. What videocard and driver do you use? Could be a> duplicate of bug #122786> > ** Changed in: evince (Ubuntu)> Importance: Undecided => Low> Assignee: (unassigned) => Ubuntu Desktop Bugs> Status: New => Incomplete> > -- > memory leak in evince?> https://bugs.launchpad.net/bugs/132612> You received this bug notification because you are a direct subscriber> of the bug.
_________________________________________________________________
Find a local pizza place, movie theater, and more….then map the best route!
http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01

[Stephen Cradock (s-cradock)]

OK, following Sebastian's question about the video card and driver I checked with the Mesa driver for my ATI Radeon Express 200M card. The glitch continues in evince with very large pdf files, even without the proprietary fglrx driver.

Stephen Cradock

----------------------------------------

> memory leak in evince?
> https://bugs.launchpad.net/bugs/132612
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
See what you’re getting into…before you go there
http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507

[Sebastien Bacher (seb128)]

did you try the workaround suggested in the other bug?

[Stephen Cradock (s-cradock)]

XAANoOffscreenPixmaps? Yes, I did. It seemed to help a little, but the huge swings in memory usage were still there, the cpu utilization was still going very high. The major difference was that the memory usage came down more quickly, so the freezing behavior was not so persistent. There is still something that isn't right, even with XAANoOffscreenPixmaps set on. It makes a difference, but doesn't approach the way evince behaves with the same file in Feisty.

Can I get a copy of evince 0.8 for gutsy? That might be the next thing to try.Stephen Cradock> From: <email address hidden>> To: <email address hidden>> Date: Tue, 21 Aug 2007 08:05:24 +0000> Subject: [Bug 132612] Re: memory leak in evince?> > did you try the workaround suggested in the other bug?> > -- > memory leak in evince?> https://bugs.launchpad.net/bugs/132612> You received this bug notification because you are a direct subscriber> of the bug.
_________________________________________________________________
Find a local pizza place, movie theater, and more….then map the best route!
http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01

[Evan Klitzke (eklitzke2)]

I am also experiencing a very bad regression in gutsy with respect to memory usage in evince. Evince has always used a lot of memory, but it seems much, much worse in Gutsy. For example, this document: http://www.stanford.edu/class/cs242/readings/backus.pdf causes evince to use hundreds of megabytes of memory. While I'm reading the document, the memory usage keeps going up until I run out of memory and start swapping. With this particular document I can go from a freshly booted system with no other applications running (< 200 MB of RAM) to a state where the system is swapping within a few minutes (I have 512 MB of RAM).

I'm using the intel video card driver (the modesetting one called "intel", not "i810"), so it seems unlikely that this is a video card issue given that I and the original bug reporter have two totally different video cards.

Is there some option in the deb that has been turned on since Feisty that could cause this (e.g. I know cairo support has been enabled/disabled many times)? Is there anything I can do to get the old memory profile from evince?

[Sebastien Bacher (seb128)]

The bug is not clear, is your issue the speed or the memory usage? Do you still get the bug? Was it better using the previous version on the same example?

[Evan Klitzke (eklitzke2)]

The issue is memory usage. Evince is just as snappy as before (maybe a little bit better in that regard due to the rendering improvements), it's just that the memory usage seems to grow and grow without bound. I have noticed this on many PDFs in Gutsy and never noticed such a problem during Feisty, so I believe it is a regression, but I'll test the same PDFs later today under Feisty and reply back when I can confirm this.

[Greg Bognar (greg-bognar)]

I have just upgraded to Gutsy, and I also experience very high memory usage -- it makes the computer unresponsive after a while. (Gutsy is now released.) This happens even if the pdf files are not large.

[bence (kerekes-bence)]

I have the same issue. Under Feisty everything was fine (maybe a bit slower). After I've upgraded to Gutsy (new evince) the problems started. If I open a 2.3 MB ( ~ 220 pages) pdf file (manual text with some black & white pictures), the evince memory usage goes up to > 50 MB. If I start to browse the pages up & down the memory usage goes up to > 100 MB and sometimes (if I stop browsing) it goes down to ~ 70 MB.

I don't think this bug depends on the file (maybe file type ?) because many of us has the same problem with various files. And it started with Gutsy.

[kripken (kripkenstein)]

I can also confirm this bug on Gutsy.

As with others here, on Feisty Evince was reasonable, but on Gutsy things are out of control. I simply cannot use Evince (I am using xpdf for now). One example is a 2.6MB PDF (I can post it here if it can help), that when opened in Evince causes 300+ MB of resident memory to be used (and I can actually see the memory taken up and swap space being utilized - this isn't a misreading of memory usage due to caching/buffers). After initial load, memory usage goes down to 200 MB, but jumps back up to 300MB+ (and 100% CPU) as I scroll.

On my 512 MB system, this behavior basically sends everything else into swap, and the system is nearly unusable. Note that even the 200MB that it 'stabilizes' on when not scrolling is bad enough.

[mp (m-p)]

Same problem here.

If I open 4-5-6 .pdfs 7-800MB RAM is used up and soon all swap space too - then Evince finally crashes/shuts down by itself.

I wonder how such an annoying bug - which basically render the computer useless in a matter of minutes - in the default viewer for one of the most used document formats can be prioritized as "low".

[R Volgers (mr-wiseman)]

Same problem here, I think. I'm working on a 500 page LaTeX document which compiles to a 25mb pdf.

If I scroll too much, evince just eats up ALL of my 1gb of memory AND my 1.2gb of swap.

It actually looks like it keeps eating memory for a while even after I stop scrolling. Sometimes I catch it just before it's eaten all my memory (I have the system monitor applets in my panel) and am able to press Ctrl+Alt+Backspace, which after a few more minutes of swapping kills my GUI and gets me a useable window manager again. I have had a couple of hard lockups because of this; I don't know why evince isn't getting killed automatically (as I would expect, and like someone else said happened for him/her).

[R Volgers (mr-wiseman)]

To add to my earlier comment, I also very much disagree with the "low" priority.

This bug that has the unexpectedly taken down my session and all unsaved work in it multiple times makes using Evince an unacceptable risk.

[mp (m-p)]

Sometimes is eats all memory very quickly - and sometimes it takes other apps down with when it crashes (this could be a Gnome thing, i dunnow).

[R Volgers (mr-wiseman)]

I've since discovered a way to kill evince when it freezes my system:

First press Ctrl+Alt+SysRq+R and then press Ctrl+Alt+SysRq+F. This should kill the process that is abusing your memory most and make your system useable again.

[Jesse Rosenthal (jesse-k-rosenthal)]

I just wanted to add that I've noticed a pattern to what sets off the extreme memory usage. If I open a file with embedded type 1 fonts, i.e. one generated by pdftex or the built-in generator in openoffice, it works just like it used to in feisty. But if I try to open a pdf that is scanned in or which uses bitmapped fonts, such as the one Evan linked to above, memory spikes and the machine becomes all but unusable.

Add my voice to the chorus of disagreement over the low priority. This is a serious bug -- at least if we consider evince a serious program. I used evince all the time in Feisty, but now it is all but useless for me except as a latex viewing program. If I want to open up a pdf that someone sends me or that I come across on the web, I have to resort to acrobat.

[kripken (kripkenstein)]

Ok, perhaps some progress on this matter.

This bothered me enough to try to get something done, so I talked to one of the Evince devs. Turns out part of the problem is that Evince always caches 2 pages forward and back. So even if you are viewing a single page, you have 5 pages rendered in memory. When pages are very 'heavy' this becomes a problem.

I have therefore written a patch to change the caching algorithm in Evince, in order to make it adaptive. The new method will cache pages ahead and back in a semi-smart manner, depending on the amount of free memory. If there is none, then it will only render pages currently in sight.

I sent the patch to the Evince dev; we'll see what they think. Meanwhile I am attaching it here as well, if someone wants to look at it, test it, etc. To do so, install Evince from svn (as explained here: http://live.gnome.org/Evince/GettingEvince ). Then apply the patch to the single file I modified (in the directory 'shell'). Then 'make install', etc.

On my 512MB system, I can now view PDFs that used to kill the computer (Evince still takes 100-200 MB, though). Results from other computers and files would be helpful, since the caching method I implemented has a heuristic for how to decide how many pages to cache, and I don't know if it is optimal in all cases. Details are inside the patch, in code comments, but basically it reads /proc/meminfo, calculates free memory, considers cached RAM and also used swap in order to decide how much should really be usable.

Comments, etc., are welcome.

(Note that this is far from solving all of Evince's memory issues. It still takes much more RAM than xPDF does, even page-for-page. But hopefully a step in the right direction.)

[tweedledee (terrywatt-deactivatedaccount)]

In regards to Jesse's comment: I tested a few files on my computer and noticed the same sort of pattern using Gutsy. If I use a PDF that has embedded fonts, Evince works fine; a 7 MB PDF uses 20-40 MB of RAM as I scroll many times throughout the document, depending mostly on when figures are loaded in memory. This is still much higher than xpdf, but Evince is also much faster, so that's fine. If I open pdf files that are scanned, the problem is much worse: a 10 MB file starts at a minimum of 50 MB and spikes to 100 MB as a I scroll a little. Moreover, as I scroll many times throughout the document, the memory use starts to creep up, and I kill evince and reload when it reaches ~700 MB (which required scrolling between two distant (100 pages apart) points maybe 50 times). I keep a memory System Monitor on my panel and close Evince before it starts to page too badly, so I've not noticed the lockups others have reported.

This was not a problem in Feisty - the memory usage on similar files was in the same initial range, but this gradual creep to fill all available RAM did not occur. As a great many pdfs do not have properly embedded fonts and I regularly scroll multiple times through files, this is a major problem. I'd like to find a solution other than installing Acrobat Reader. (kripkenstein: unfortunately I'm only using my primary machine at the moment, so don't want to test your patch in the event of a major side effect.) Keeping multiple copies of Evince running on the same file solves the memory creep problem, but if I need more than 3-4 copies open at once to view different locations, then the total memory usage is still very high.

For what it's worth, I'm using the open source ati driver on a fresh Gutsy install with 1 GB RAM and same size swap.

[kripken (kripkenstein)]

There is now a formal bug on the GNOME bugzilla tracker about this matter,

http://bugzilla.gnome.org/show_bug.cgi?id=504913

Perhaps people from here can add comments confirming the issue, example PDF files on which it occurs, etc., so the Evince devs are convinced of the severity of this issue.

[kripken (kripkenstein)]

What I believe is the main cause of this bug has been discovered. Details are in a comment I left on the GNOME bug report.

Briefly, the issue is that in scanned PDFs, each page contains an image. Evince, unlike simpler viewers, allows users to copy images. Problem is, the images are prepared in advance when the page is loaded. On a scanned PDF, the images are of the size of the _original_ scanned page. In an example PDF here, each such page is 4000x4000 pixels, which means 64 MB per page. Caching 4 pages in addition to the current one means over 300 MB of RAM is used - very problematic (the actual pages, rendered at say 1024x786, should only take around 4 MB each, for 20 MB overall). I again reiterate that I believe the severity of this bug should be higher than 'low'.

It is unclear how GNOME will respond. A correct solution would only prepare the images for copying only when an actual copy request is made, but this necessitates various changes, including to Poppler and perhaps other rendering backends as well for the other formats aside from PDF.

Meanwhile, if this is not solved in time for Hardy, I suggest that Ubuntu consider disabling image copying in Evince, especially since Hardy is an LTS release. I attach a tiny patch that does so. The only functionality lost is that one cannot copy images by right clicking or dragging them, which is probably a rare behavior anyhow (and one can of course still take a screenshot and get the desired part out of it). The advantage is that Evince will not have unacceptable memory behavior on certain PDFs. On my example PDF, patched Evince uses 38 MB instead of over 300 MB.

[Brian Pitts (bpitts)]

This has been possibly fixed in evince svn and poppler git.

http://bugzilla.gnome.org/show_bug.cgi?id=504913#c8

[kripken (kripkenstein)]

Partially fixed, as I understand it. The images issue I mention in my comment above has been solved, however, the other issue of tiled rendering has been postponed for GNOME 2.24. Both issues are fairly serious, so this is good progress, but there are still PDFs on which Evince is not usable on medium- to low-memory machines.

[tweedledee (terrywatt-deactivatedaccount)]

For what it's worth, this is definitely not resolved in Ubuntu Hardy - I had a 300 KB PDF using 900 MB of RAM earlier today. It was an old research artcle that had been scanned in, and although it was OCR'd, Evince was still treating it as an image for memory purposes (although I could copy text out just fine). At that level, this could easily be an issue for high-end machines as well, and unfortunately strongly encourages the use of Adobe Reader.

[kripken (kripkenstein)]

tweedledee: Yes, as I mentioned above, this is only partially fixed, serious issues remain.

The Evince devs intend to implement tiled rendering (which should fix this) for the next version in 6 months, so we can hope for that.

[Jørgen Kristoffersen (jorgekri)]

I can confirm this bug in Hardy Heron x86_64. A small scanned file quickly uses over 400MB of memory. <strong>Also</strong>, Evince does not free up all the memory when I close the offending document.

Case: (All listed memoryusage is only for the evince-process)
I open two non-scanned mostly text documents and browse through them. Memoryusage: 44 MB.
I open a scanned purely image document, 8 pages 2.5 MB file: Memoryusage before browsing: 257MB.
Memoryusage after browsing through the document: 373MB
Memoryusage after closing the scanned document, keeping the other two up: 177MB
Opening a new scanned document and browse it: 512 MB
Closing this again, still keeping the two text-documents up: 379 MB.

As you can see, the memoryusage escalate as I open and close new documents.

[mp (m-p)]

How does a memory leak in the default viewer of one of the most used document formats remain unimportant across several distributions?

I cannot quite fathom what would constitute something of importance.....

[Sebastien Bacher (seb128)]

that's not a memory leak issue but rather a design one and it's being worked

[Matt (matt-mattford)]

What is the progress on this bug? I echo the sentiments of mp - this should be higher priority!

[Pedro Villavicencio (pedro)]

according to upstream this is already fixed on svn:

"This is already fixed, it requires poppler >= 0.8.

Thanks. "

[Sebastien Bacher (seb128)]

and intrepid has poppler 0.8.5 so closing the bug

[Stephen Cradock (s-cradock)]

As the original submitter I can confirm that the memory problems are no longer apparent in Intrepid - evince 2.23.5, libpoppler 0.8.4 (cairo). Large page-scanned documents open and page fine, as far as I can see, without eating memory to any noticeable extent.

Thanks everyone for getting this fixed!

[jmspeex (jean-marc-valin)]

I'm currently running Intrepid and the problem is *not* fixed. I was wondering why my system was still using a lot of memory despite the fact I didn't have that many apps running. So I closed all by one of the evince documents and checked memory use:

% free
             total used free shared buffers cached
Mem: 4045452 3975256 70196 0 126200 617356
-/+ buffers/cache: 3231700 813752
Swap: 3903784 1433792 2469992

I count only the used "-/+ buffers/cache" plus the used swap, so that's 4.4 GB used by the system. I then close the last evince document and check memory again.

% free
             total used free shared buffers cached
Mem: 4045452 3057952 987500 0 126304 613112
-/+ buffers/cache: 2318536 1726916
Swap: 3903784 533184 3370600

Using the same method, that's 2.7 GB use (still too much, but that's another issue). So evince was *effectively* using 1.7 GB just to display one document (plus most likely the leaks from the documents I opened and closed). No, there was nothing special about the document I had open.

[Sebastien Bacher (seb128)]

you should open a new bug and not comment on a closed one