GNOME Bugzilla – Bug 159268
GPDF takes down the system when opening PDFs with full-page bitmap images
Last modified: 2009-08-15 18:40:50 UTC
With certain PDF documents, apparently those which are made up of ful-page scanned images, GPDF makes my system completely unresponsive; I can see the hard disk light going all the time so my best guess is that it's allocating memory like mad and pushing everything else out to swap. (I'm also basing this guess on the fact that I once managed to get to another VT and saw OOM killer messages spewing, and I didn't have anything heavy running). Unfortunately I have been rather unsuccessful at debugging this problem as when this happens the only way I have found to get control over the computer again is to kill X (which works if I'm lucky). After that I can't find any sane signs of what happened. Everything in my desktop grinds to a halt when this happens - rhythmbox stops playing, the screen image freezes etc. The PDFs I have seen this happen with are scanned research papers,available at http://prola.aps.org (the examples I have that consistently make this happen are papers from 1990). Because of copyright issues I don't think that I can post the papers to bugzilla; however, I think that it's within fair use for me to provide them privately for bug chasing purposes, so I'll be happy to provide a couple of sure killers by e-mail on request.
Uhh, before you chase after PDFs, the PROLA site is only accessible if you have a subscription, which generally means that you're at a university with a subscription. If you're not, don't waste your time there, just e-mail me instead. Sorry I didn't make that clear in the report.
Before I ask for such a file: are the scanned images monochrome (i.e. could they have bit-depth 1)? If yes, I can imagine that this causes OOM kills. Unfortunately, gpdf converts all images to 32-Bit rgba (because that's the only format gnome-print does handle). And I know that inside gnome-print (or gnome-canvas) the rgba data is copied at least once. So the memory consumption for monochrome images is at least 64 times as big as necessary. When gpdf switches from the gnome-print backend to the new (well, 1-year-old) xpdf 3 backend, this bug will be among the fixed bugs.
Yes, I believe that the images are scanned at 600 dpi at bit-depth 1, and they cover the full page. With the 64-times expansion you mentioned it seems that this corresponds to 256 MB per page. If several pages get stuffed in memory at once I guess this might be a severe problem. Looking forward to the Xpdf 3.0-based version...
Oops.. Seems I didn't get the closing reason in there. This seems to be the same bug as bug 160067, where there's a testcase. Likely the fix is to use Evince instead, it doesn't appear to have the problem.