evince consumes a lot of memory (1.5 GB VM)

[Sebastian Urban]

Binary package hint: evince

steps to reproduce:

1. open http://www.physik.tu-muenchen.de/lehrstuehle/T39/T39_files/Lectures_files/QuantumMechanics2007/QM07_Kap7.pdf
2. add "zoom in" and "zoom out" buttons to your toolbar (i'm not sure if this is really needed, but I reproduced the problem in this way)
3. switch on continous-mode
4. scroll (slowly) to the bottom of the document
5. click on "zoom in" till zoom level reaches 200 %
6. scroll (slowly) to the top of the document

result:
evince consumes about 1,5 GB vm-memory (600 mb writeable).
system becomes very slow.

If the steps do not work for you, try zooming in and out again.
I verified this with compiz running, 1 GB physical RAM, 2 GB swap.

ProblemType: Bug
Architecture: amd64
Date: Sun Sep 9 01:03:01 2007
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/bin/evince
Package: evince 2.19.92-0ubuntu1
PackageArchitecture: amd64
ProcCmdline: evince file:///home/surban/Uni/Theoretische%20Physik%203/Vorlesung/QM07_Kap6.pdf
ProcCwd: /home/surban
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: evince
Uname: Linux gastgeber 2.6.22-10-generic #1 SMP Wed Aug 22 07:42:05 GMT 2007 x86_64 GNU/Linux

[xtknight (xt-knight)]

Confirmed. I got it to use this much.

19435 andy 15 0 1114m 863m 20m S 69 21.8 0:27.46 evince

[Pedro Villavicencio (pedro)]

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=475612

[Pedro Villavicencio (pedro)]

Would be useful to have a valgrind log please try to obtain one following the instructions at https://wiki.ubuntu.com/Valgrind and attach the file to the bug report.

[Sebastian Urban (surban)]

Valgrind does not seem to work for me. Crashes on startup.

Logfile is attached.

[Sebastian Urban (surban)]

Also reproducible on i386.

Valgrind log is attached.

[Bryn (bryn-hughes)]

I have had similar problems with both 32-bit and 64-bit versions. Also, I have set it on both continuous and non-continuous displays, and it still spikes the RAM usage to about 500MB.

[Albert Damen (albrt)]

http://www.tfh-berlin.de/~rudolph/signale/skripte/SuS_SS06/Shannon_Limit.pdf (from dup bug 154526) is another example taking a lot of memory. It can crash a 512 MB system, without doing anything special.

[SFeek (sfeek)]

I have this same issue on P4 1.4GHz machine with 256Mb of RAM. It slows my cursor to a crawl as it quickly uses all of the remaining free RAM, and finally crashes. I can see in /var/logs/messages where the system is trying very hard to recover the "lost" memory after the program closes. The system returns to normal after a short period of drive activity.

[LuitvD (luitvd)]

I have the same on my machine. I was puzzled by the excessive use of swap on my laptop (amd64 with 800MB RAM) so I disabled swap and waited for something to fail. It happened when I was scrolling through an ADC0804 datasheet (simple chip datasheet with quite an amount of images). It suddenly failed to move my mouse easily, and shortly after Evince disappeared, and took OpenOffice Writer down with it.
A next try with swap turned back on showed that Evince was using 500 MiB of memory (not VM, just regular memory space) which made my laptop dump half of it's system memory to swap, making it slow and unresponsive.

[dennis1200 (dennis-fiser)]

Similar problems here on an AMD 1.8GHz w/ 1GB of RAM. It is definitely only pronounced on scanned pdf files as opposed to searchable, copy-able text (or maybe anything larger than 1MB). Scrolling down, the RAM usage jumps by 50-100MB for each page I go through, and doesn't come back down. I've attached a shot of my system monitor - you can clearly see where CPU usage and RAM usage go through the roof (I opened and closed it twice). And this is only a 20-page, 2MB pdf... But based on how much ram is being used - it would totally crash a system with <1GB of RAM.

For the "regular" searchable pdf (151KB), memory only goes up by about 30MB total (still a bit much, in my humble opinion).

[Henrique Ferreiro (henrique-ferreiro)]

For me, it happens with a pdf made with latex which include a lot of big images and the pdf's size is 147 MB.

[Rebecca Palmer (rebecca-palmer)]

I have the same problem with http://uk.arxiv.org/pdf/0801.4754 (amd64 Gutsy); Valgrind log attached. The trigger appears to be the picture at the bottom of page 9.

[Rebecca Palmer (rebecca-palmer)]

Still happens in amd64 Hardy alpha2 (2-3GB with my example, the trigger now being the *top* image on page 9) but now recovers itself on scrolling away from the triggering image, while under Gutsy it was necessary to close Evince completely.

May be related to bug 188079.

[Miguel Martinez (el-quark)]

In my laptop, evince crawls every time I open a scanned Physical Review paper (i.e. older than 1995). However, xpdf works flawlessly. A lot of examples can be found in the Physical Review Letters milestone papers, which I think anyone can access:
http://prl.aps.org/50years/milestones

I must say that I've seen this happen on my laptop (ATi card + free radeon driver) and on a Debian Testing PC (Intel), but a Core Duo laptop with nVidia graphics and running Xubuntu Gutsy opened a "dangerous" pdf fine. Can this be related to the graphics card or the driver? I'll try fglrx to see if that changes anything.

[dorphichinfa (dorphichinfa-deactivatedaccount)]

I have recently been hit by this bug on Gutsy.

Opening http://www.foxkeh.com/downloads/history/history-foxkeh.pdf resulted in 600MB memory usage in "Best Fit" zoom level (about 70%), little did I know that trying to zoom in to 400% to get a closeup of one of the images would result in Evince consuming all 1GB of my memory and 2.5GB of my swap, grinding my system to a halt to the point of me needing to cut the power.

Yes. Ouch.

[Kevin Sopp (baraclese)]

The problem seems to persist in Ubuntu 8.04 (Evince Document Viewer 2.22.1.1)
I encountered it on the following file
http://standards.iso.org/ittf/PubliclyAvailableStandards/c018939_ISO_IEC_10967-1_1994(E).zip

My machine has a measly 256MB RAM and it hits the swap partition hard. At that point the system becomes pretty much unusable. I use xpdf to view this file now. Of course things aren't fast there either but at least it doesn't eat up all my RAM and I can continue working.

[Igor Zubarev (igor.zubarev)]

Confirm. Evince hangs opening all files in MAXIMIZED mode.

[illuminatedtiger (illuminatedtiger)]

Same issue. 8.04 Beta. Only happens with this one particular file for me (attached). My system quickly crashes. Memory usage soars above 700 megs!

[Joakim Asplund (megajocke)]

This PDF with a scanned schematic eats up all my memory when I open it:
http://www.crownaudio.com/pdf/legacy/MT-1000schematic.PDF

The mouse cursor gets choppy, starts missing input etc. Once it took me ten minutes to be able to close down Evince. Now this part is of course not a problem with evince - but is this really the way it's supposed to be? Other OS:es never do this - mouse cursor always responds regardless of how much thrashing is going on. Could it be something like the X-server being swapped out? CPU usage never peaks during this period.

[Miguel Martinez (el-quark)]

I've just added the following comment in the upstream bug:

"Does the bugfix just require to update poppler to 0.8.4 (current as of today)? Or does it also need patches presented here? It's a shame if a full poppler 0.8 is required, since this will probably leave Ubuntu Hardy users in the dust. Oh, well, there's always xpdf."

Does anybody here if hardy users will be able to enjoy this bugfix?

As a sidenote, since the gutsy kernel ubuntu has sucked quite a bit during high IO processing. Hardy is somewhat better but high IO really kills gutsy, while 100% CPU usage has never been an issue. Joakim might want to have a look at bug #131094

[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

[Dominik Holler (dominik-holler)]

I want to highlight that even if this bug is marked as "Fix Released " neither this bug of Gutsy nor the aequate bug in current hardy is fixed.

[Sebastien Bacher (seb128)]

right bugs are closed when they are fixed in the current unstable ubuntu version, then backport tasks can be opened if required

[Miguel Martinez (el-quark)]

Is there really any chance of backporting poppler from Intrepid? I've
done a quick search in synaptic (I admit I don't know how to search for
dependencies via aptitude) and default ubuntu packages that depend on
poppler (and might need to be recompiled and put into backports) are
evince (obviously), cups, gimp and tracker. Other important packages
depending on poppler are inkscape, kpdf, krita and texlive-base-bin.

On Thu, 31 Jul 2008 20:02:36 -0000 Sebastien Bacher <email address hidden>
wrote:
> right bugs are closed when they are fixed in the current unstable
> ubuntu version, then backport tasks can be opened if required
>

[Sebastien Bacher (seb128)]

the new poppler 0.8 will not be uploaded to hardy or backported no, the API and ABI changed which means applications might require code changes or behave in an unexpected way, that's not something to change on a stable version

[Rebecca Palmer (rebecca-palmer)]

http://uk.arxiv.org/pdf/0801.4754 still triggers this in amd64 Intrepid on my system, using about 1.5GB before it gives up and shows a blank page; while as in Hardy scrolling away from the trigger image (top of page 9) is enough to recover, this still prevents the contents of that page being viewed, and takes a while before the subsequent pages can be viewed.

I have not tried the other test files, but as the trigger in this file is a pair of fairly simple pictures that appear to be vector graphics while I've never had a problem with the large scanned bitmaps the fix appears to be designed for, I suspect my bug may be a separate one from the bug that was fixed, possibly more closely related to bug 188079.

While it is possible that the test file itself contains an error, it can be opened in Adobe Reader under Windows, and viewing page 9 there uses 50MB.

[Sanket Totewar (sunk8)]

Evince works fine for pdf files less than about 20 MB. However when I opened a 23 MB file, it started eating all my RAM and swap. The memory went upto 945 MB and then I had to restart the PC. Not even alt+ctrl+backspace worked (it's enabled).

Pity, that the adobe reader opens the file and runs it flawlessly within 40 MB.. When I split the file in 2, it runs well so I guess it's the size. Zooming in a small file sometimes causes the same issue.

I'm attaching a screenshot of my system monitor. Took me quite an effort to get it, as evince would not let any other program run. Even the mouse was 'stunned'. On the Resources tab, pie charts of Memory and swap are both filled up... :-(

Some more info:
Evince version: 2.30.1-0ubuntu2.
Linux kernel 2.6.32-22-generic.
Intel 845 chipset running a 64-bit Ubuntu 10.04 with latest updates (from the main server).

[Miguel Martinez (el-quark)]

In order to check the current evince behaviour, I opened again the pdf linked by Rebecca Palmer. The maximum memory usage I saw using system monitor was 55 Mb, when scrolling through pages 21-22. As soon as I passed those two gnuplot graphs, memory usage dropped to about 30 Mb. Bear in mind that the initial memory usage is 20 Mb. This is on a fully updated 64bit lucid install.

Can anyone post a link to a file triggering the events? The heaviest file I probably have is a paper from Review of Modern Physics, Rev Mod Phys 62, 1045 (1992). It is made of 53 scanned pages, and is 11 Mb. The biggest memory usage I've seen when torturing evince is 144.5 Mb, and I will recover memory when I stop scrolling like crazy. In comparison, acroread has a maximum memory usage of 46 Mb... but the scrolling there plainly sucks.