GNOME Bugzilla – Bug 570667
Evince crashes when trying to print pdf
Last modified: 2018-05-22 13:28:37 UTC
Steps to reproduce: 1. Download http://www.comesafety.org/fileadmin/uploads/architecture/COMeSafety_European_Communications_Architecture.pdf 2. open it in evince 3. select print from file menu Stack trace: Other information: Evince crashes but does not exit. it keeps CPU at 100% trying to do something. The same document prints fine using fox reader (in wine).
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!
Created attachment 128096 [details] Bug trace for crash The application crashes as in does not produce a crash trace but keeps on showing loading in the document and the cpu spikes at 100%. If I click two or three times in the main window, then it crashes. I am including the crash trace here...
Created attachment 128100 [details] Video of problem This video illustrates the problem. Notice how after I choose file->print the cpu goes to 100%. Then I move the sidebar and it keeps on loading. Finally, if I click many times in the loading document view, evince crashes. Needless to say, nothing gets printed. Print to File seems to work ok though. BTW, this is all in Fedora 10 with kernel from Fedora 11. I have not tried stock F10 kernel, don't know if it matters. Also, I noticed something else. The document is image-heavy. If I view it and start scrolling down using PgDn and I keep clicking the mouse button whilst the view scrolls, in a few seconds I get a crash (with a crash log). This doesn't happen with other documents. Finally, note that the document in question (link in bug report) can be freely downloaded, it is intended to be read and commented upon, so you are legally allowed to download and examine it.
Thanks for the so useful bug report. We have reworked the printing stuff in trunk. I think this problem is already fixed, but I'm not 100% sure. Could you upgrade evince to >= 2.25.4 and try again, please? There are several pages in the document that take a little longer to render, but it should work anyway.
Created attachment 128388 [details] Video of crash with latest evince and poppler Ok I got the latest unstable evince (not svn), compiled it and the problem persists. I then tried with the latest stable poppler 0.10.3 (did't know if it would make a difference) and the problem is still there. I know now however that the printing crashes evince on page 103 (because of the indicator). In fact, in the attached video, you will see I try to print pages 101-103 and it crashes on the last page. So I thought I might separate only those pages of interest. To do this, I decided to use print-to-file (because I knew that worked) for only those pages. And it seems the end product was a 155MB file!! I am almost certain there is something up with the picture in page 103 of the document.
Created attachment 128458 [details] if evince is left running, even at 100% cpu usage, eventually this appears After trying to print again, this time I let evince run even though it appeared to be stuck. Then, after 30 mins or so it came up with an empty titled dialog box which said Failed to print document Too many failed attempts. So evince does not really crash but something fails continuously. Note how the CPU stops spiking after the 20min delay, and everything is back to normal (i.e. the evince window refreshes properly after this).
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Reopening as requested info had been provided.
Hi, I tried to reproduce this bug and I couldn't find the original pointed document, so I took this file: http://www.comesafety.org/uploads/media/COMeSafety_DEL_D31_EuropeanITSCommunicationArchitecture_v2.0_01.pdf I can't crash Evince with this one. But, anyway, I noticed a very strange behavior on page 103 which produce a lot of warnings and slow the printing process. It is very likely due to the figure on the top of the page. Could these crashes (or denial of service) be produced by a timeout which had been set too low when the PDF to PS translation hit some complex translation work ?
With the document from the previous comment, I also get a lot of CPU use and an error dialog box saying that my root partition is out of space, then a Print error dialog box saying "there was a problem processing document" and the page is not printed. I guess everything would be fine if there was enough disk space.
Tried to print the pdf into a PS file (I don't have any printer connected atm) and it worked perfectly (evince 3.6.0 here). Maybe this bug is already fixed, or do I need a real printer connected?
Created attachment 226471 [details] Problematic PDF page PDF page from a file which used to choke (freeze) evince in the past when printing. Still today if you try to print it, it results in a massive 180MB file sent to the printer! This page is 269kb on disk. If you print it, you get 163MB file(!)
I extracted the page from the document in the original bug report document which can now be found at http://www.esafetysupport.org/download/eSafety_Studies/COMeSafety_Architecture_Documents/COMeSafety_European_Communications_Architecture.pdf The bug report is still valid today - I narrowed down the problem to this page (103) which I extracted from the original pdf using PDF Mod v0.9.1 I think if someone looks into this small 243kb file they will easily realise what is wrong and maybe fix it :)
ok, indeed generated .ps file is huge. Did not notice probably because I've got SSD and i7 CPU here so it wasn't that slow to generate.
Nearly every string in that file is set (o)(n)(e) (g)(l)(y)(p)(h) (a)(t) (a) (t)(i)(m)(e). There are also a tremendous quantity of small inline images. (The one-page attachment has nearly 80000.) The only reason the original pdf has a reasonably size is that the majority of each page is deflated. The conversion from pdf syntax to ps syntax explodes the filesize. Even just decompressing the pdf’s streams (I used mupdfclean -d) generates a *much* larger pdf. Were poppler to use eg ashow or kshow or the like it could compress the generated ps by outputting fewer, longer strings with their respective kernings. Whether ps interpreters would slow down more from the added complexity than they do from the longer, status quo bit stream is unknown. OTOH, coalessing the small images into fewer, larger images ought to be generally beneficial.
Can anybody reproduce the issue with a newer evince/poppler? With evince/poppler master, the PS is 27MB. I see performance issues in rendering, though. It takes ~5-6 seconds in Evince, whereas in poppler-glib-demo it renders the page in 2.266 seconds. The selection in Evince takes more or less the same time to show it, in poppler-glib-demo it is immediate.
This is likely a problematic document. It is still not printing with evince 3.20, but it's no longer crashing. Perhaps this should be moved to Poppler.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/78.