cups (poppler) pdf printing memory leak/inifinite loop

As we do not get the same complaint from other users it probably depends much on which files you try to print. So can you please attach typical files with which the problem occurs?

Can you also attach an error_log of such a failure, following the instructions here:

https://wiki.ubuntu.com/DebuggingPrintingProblems

Here is a sample file, this file eats up all my memory when I try to print it on my 9.04 machine, however it prints fine on a 8.04 Server, and it prints fine from evince.

One can simply reproduce it with a line like

/usr/lib/cups/filter/pdftopdf 1 1 1 1 "" 2450380.pdf > out.pdf

Got a fix from the upstream author of pdftopdf and tested it. It works. Applied the fix to the Debian BZR repository of CUPS. So it will be in the next CUPS package for Karmic.

This bug was fixed in the package cups - 1.3.10-3

---------------
cups (1.3.10-3) unstable; urgency=low

  [ Till Kamppeter ]
  * debian/cups.install, debian/rules: Move added *.convs and *.types files to
    /usr/share/cups/mime/ so that they are not considered config files
    by dpkg.
  * debian/local/text.convs: Turn all text input formats to text/plain at
    a high cost, so that the text-only printer (which accepts only text/plain)
    accepts them (LP: #385797).
  * debian/rules: Switch the pdftops filter back to Poppler, as Ghostscript
    has a lot of problems in generating PostScript (LP: #382379).
  * debian/patches/poppler-based-pdftops-fixes.dpatch: Fixes for the pdftops
    filter in Poppler mode: Do not emit PostScript level 3 as it Poppler's
    PostScript level 3 output is not compatible with HP's PostScript printers
    (LP: #277404); Added support for the new "-origpagesizes" option of
    Poppler's pdftops, so that documents with pages of different sizes get
    correctly printed (LP: #310575).
  * debian/filters/pstopdf: Do not call Ghostscript with asymmetric resolutions
    (like 1200x600 dpi), as it leads to problems with images in some cases.
    See http://bugs.ghostscript.com/show_bug.cgi?id=690504.
  * debian/local/filters/pdf-filters/pdftopdf/P2PObject.h,
    debian/local/filters/pdf-filters/pdftopdf/P2POutput.cxx: Fixed infinite
    loop which occured for some PDF files (LP: #382880).
  * debian/filters/pstopdf: Make it also correctly working if PaperDimension
    and ImageableArea entries in the PPD have no translation strings. Thanks
    to Koji Otani to find the bug.
  * debian/local/filters/pdf-filters/pdftoopvp/,
    debian/local/filters/pdf-filters/README,
    debian/local/filters/pdf-filters/addtocups,
    debian/local/filters/pdf-filters/removefromcups,
    debian/local/filters/pdf-filters/config-scripts/cups-pdf-filters.m4:
    Added pdftoopvp CUPS filter as part of the PDF filter add-on.
  * debian/cups.install: Make /etc/fonts/conf.d/99pdftoopvp.conf of pdftoopvp
    be installed as part of the cups package
  * debian/control: Added build dependencies needed by pdftoopvp: liblcms1-dev,
    libfreetype6-dev, libfontconfig1-dev
  * debian/control: Moved dependency on cups-client to Depends:, as
    cups-client is needed by the post-install script for the update of the
    PPDs of existing print queues.
  * debian/cups.postinst: Case-insensitive check for model names when updating
    PPDs of already existing print queues.

  [ Martin Pitt ]
  * Add gnutls-pkgconfig.dpatch: Use "pkg-config gnutls" instead of deprecated
    libgnutls-config. (Closes: #529903)
  * Bump Standards-Version to 3.8.1 (no changes necessary).
  * debian/control: Point Vcs-Browser: to bzr.d.o. loggerhead, and use http://
    URL for Vcs-Bzr.
  * debian/control: Drop ghostscript build dependency again, pdftops filter
    uses poppler again. Also Drop alternative xpdf-utils build dependency,
    since configure now checks for poppler's pdftops capabilities.
  * debian/control, debian/rules: Do a build-time check if pdftops supports
    -origpagesizes, and dynamically set the poppler-utils dependency. This is
    a hack until https:/...

I seem to have the same problem in 9.10, using cups 1.4.1. Printing certain PDF files will cause pdftopdf to grab all the memory it can get. My current workaround is to print to a .ps-file and then print this ps file. Should I open a new bug or reuse this one?

Cheers,
Ole

Example PDF document causing the problem for me

As this is already marked as fix released. It's probably not the same exact issue. In either case, It'd probably be better to post a new bug, as this one will not be watched.