GNOME Bugzilla – Bug 581657
On certains PDFs, evince's memory consumption grows up to fill all the available memory.
Last modified: 2012-11-04 22:25:17 UTC
Please describe the problem: When opening certains PDFs, evince's memory consumption grows up very quickly and makes evince and the whole computer unusable a few seconds after. I looked at the bug report 504913 which seems to be the same problem, but it was supposed to be fixed in evince 2.22.2 and my evince's version is 2.26.1, and it is not hundreds of megabytes but gigabytes ! Steps to reproduce: 1. (optional) Add an panel-applet to see the memory and swap consumption in real time 2. Open the 1MB file http://www.ens.fr/concours/Rapports/2008/MP/mppc_sujets_lv1.pdf in evince 3. Try to select "Session 2008" (yes, this is an image, but do as it was text) Actual results: First, evince doesn't respond anymore (on Ubuntu the window becomes grey) and the memory consumption grows of about 300MB and stabilizes. After a few seconds a new window titled "image-0" opens (perhaps another title if you have another locale than the french one), and then the memory consumption grows up indefinitely at a rate of about 80MB/s (i.e. 1GB in 12 seconds !) on my computer. When evince begins to use the swap file, it is very difficult to close it because the whole system is considerably slow down (I have 2GB RAM and 2GB swap) Expected results: evince would not use more than a few MB of memory. Does this happen every time? On this file and some others yes, but it doesn't happen on every pdf file. Other information: This file works fine with acroread or xpdf. I'm french, so feel free to correct my english mistakes :)
Thanks for taking the time to report this bug. Without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
This appears to be the same as Ubuntu bug 481459, https://bugs.launchpad.net/evince/+bug/481459 There is a sample PDF linked to that report. evince doesn't crash out, just becomes nonresponsive and starts chewing memory.
Created attachment 147639 [details] PDF document producing the memory leak I confirm the memory leak. I'm attaching the PDF file here to ease the developer work. The pdfinfo on this file give: Producer: GNU Ghostscript 5.50 CreationDate: Sun Nov 12 17:00:08 2000 Tagged: no Pages: 36 Encrypted: no Page size: 612 x 792 pts (letter) File size: 682578 bytes Optimized: no PDF version: 1.2 I did also run a valgrind on it to see what was happening and get at least the start of a trace. It seems to be located there: ==30619== 4627 errors in context 12 of 12: ==30619== Thread 2: ==30619== Conditional jump or move depends on uninitialised value(s) ==30619== at 0x4E68CD6: Gfx::go(int) (Gfx.cc:672) ==30619== by 0x4E69671: Gfx::display(Object*, int) (Gfx.cc:638) ==30619== by 0x4628755: _render_type3_glyph(_cairo_scaled_font*, unsigned long, _cairo*, cairo_text_extents_t*) (CairoFontEngine.cc:623) ==30619== by 0x4828428: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x481E7AA: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x481F40C: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x48255D9: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x4821BF1: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x48099D4: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x480333C: cairo_show_glyphs (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x462D249: CairoOutputDev::endString(GfxState*) (CairoOutputDev.cc:883) ==30619== by 0x4E6E446: Gfx::doShowText(GooString*) (Gfx.cc:3683) ==30619== Uninitialised value was created by a heap allocation ==30619== at 0x40253C5: operator new(unsigned int) (vg_replace_malloc.c:214) ==30619== by 0x462868D: _render_type3_glyph(_cairo_scaled_font*, unsigned long, _cairo*, cairo_text_extents_t*) (CairoFontEngine.cc:619) ==30619== by 0x4828428: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x481E7AA: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x481F40C: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x48255D9: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x4821BF1: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x48099D4: ??? (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x480333C: cairo_show_glyphs (in /usr/lib/libcairo.so.2.10800.8) ==30619== by 0x462D249: CairoOutputDev::endString(GfxState*) (CairoOutputDev.cc:883) ==30619== by 0x4E6E446: Gfx::doShowText(GooString*) (Gfx.cc:3683) ==30619== by 0x4E6E885: Gfx::opShowText(Object*, int) (Gfx.cc:3425) ==30619==
Created attachment 147640 [details] Full valgrind trace
Could this be a problem with high-resolution bitmap fonts? I see it generally when reading poorly-set PDFs from dvipdf with 8000-dpi Type 3 embedded fonts.
(In reply to comment #3) > Created an attachment (id=147639) [details] > PDF document producing the memory leak > > I confirm the memory leak. I'm attaching the PDF file here to ease the > developer work. This is a different bug. Can you open a new one for this PDF file? I can trigger more memory consumption with this PDF, but not with the reported originally in this bug.
(In reply to comment #0) > Please describe the problem: > When opening certains PDFs, evince's memory consumption grows up very quickly > and makes evince and the whole computer unusable a few seconds after. > I looked at the bug report 504913 which seems to be the same problem, but it > was supposed to be fixed in evince 2.22.2 and my evince's version is 2.26.1, > and it is not hundreds of megabytes but gigabytes ! > > > Steps to reproduce: > 1. (optional) Add an panel-applet to see the memory and swap consumption in > real time > 2. Open the 1MB file > http://www.ens.fr/concours/Rapports/2008/MP/mppc_sujets_lv1.pdf in evince > 3. Try to select "Session 2008" (yes, this is an image, but do as it was text) Guillaume, Please, could you try with a newer version? I can not reproduce it your bug. I tried evince from master (next to 3.5.90) and 3.4.0, and both of them work fine.
I still see it with evince-3.4.0-2.fc17.x86_64 and the sample document at https://bugzilla.redhat.com/attachment.cgi?id=497631 . You have to keep selecting text to get the memory binge (~1.5 GB in a matter of seconds).
(In reply to comment #8) > I still see it with evince-3.4.0-2.fc17.x86_64 and the sample document at > https://bugzilla.redhat.com/attachment.cgi?id=497631 . You have to keep > selecting text to get the memory binge (~1.5 GB in a matter of seconds). I see more memory consumption. However, this seems to be a different bug than the one reported. In document reported was an image, when selecting a part of the image, evince started to use more resources. I can not reproduce that behaviour. The problem you mention involves text, not image and I can reproduce it. That is the reason I asked to open a different bug.
(In reply to comment #9) > The problem you mention involves text, not image and I can reproduce it. That > is the reason I asked to open a different bug. OK, sorry for the confusion... I think I saw Type 3 fonts in the original doc and assumed it was the same issue.
(In reply to comment #10) > (In reply to comment #9) > > The problem you mention involves text, not image and I can reproduce it. That > > is the reason I asked to open a different bug. > > OK, sorry for the confusion... I think I saw Type 3 fonts in the original doc > and assumed it was the same issue. BTW, the bug seems to be in poppler.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > The problem you mention involves text, not image and I can reproduce it. That > > > is the reason I asked to open a different bug. > > > > OK, sorry for the confusion... I think I saw Type 3 fonts in the original doc > > and assumed it was the same issue. > > BTW, the bug seems to be in poppler. I filed the bug in freedesktop. https://bugs.freedesktop.org/show_bug.cgi?id=54945
Closing this bug as NOTGNOME. Please, follow the report in https://bugs.freedesktop.org/show_bug.cgi?id=54945 For more information, see https://live.gnome.org/Evince/PopplerBugs#poppler