[poppler] infinite running pdftops

[Matt LaPlante]

On Thu, Feb 3, 2011 at 6:20 PM, Albert Astals Cid <aacid at kde.org> wrote:

> A Dijous, 3 de febrer de 2011, Matt LaPlante va escriure:
> > On Thu, Feb 3, 2011 at 5:23 PM, Albert Astals Cid <aacid at kde.org> wrote:
> > > A Dijous, 3 de febrer de 2011, Matt LaPlante va escriure:
> > > > I occasionally run into cups servers in which pdftops will be running
> > > > seemingly forever against a single pdf.  Currently we're using
> 0.16.1.
> > > > I would love to be able to provide one of the PDFs in question, but
> > > > unfortunately this is a business environment and most of the files
> are
> > > > confidential.  I'm hoping there is some other way we can work towards
> > > > debugging the situation.
> > > >
> > > > I have one such pdf sitting in front of me now.  The pdftops
> > >
> > > -origpagesize
> > >
> > > > -level2 [pdf] just keeps churning and churning.  It produced a
> sizable
> > >
> > > .ps
> > >
> > > > file almost immediately, then it just stops writing data, even though
> > > > the process is still running.  The .ps file never appears to grow,
> > > > even if
> > >
> > > left
> > >
> > > > for several more minutes.  This behavior hangs up cups something
> awful,
> > >
> > > but
> > >
> > > > I can also reproduce it manually.
> > > >
> > > > I fired up the process in gdb, waited for a few minutes, and then
> > > > stopped the process.  Each time, the output was:
> > > >
> > > > 0x00007ffff7b3e254 in Splash::pipeRun (this=<value optimized out>,
> > > > pipe=0x7fffffffd350) at Splash.cc:402
> > > > 402     Splash.cc: No such file or directory.
> > > >
> > > >         in Splash.cc
> > > >
> > > > 0x00007ffff7b3e269 in Splash::pipeRun (this=<value optimized out>,
> > > > pipe=0x7fffffffd350) at Splash.cc:405
> > > > 405     Splash.cc: No such file or directory.
> > > >
> > > >         in Splash.cc
> > > >
> > > > Splash::pipeRun (this=0x7872d0, pipe=0x7fffffffd350) at Splash.cc:399
> > > > 399     Splash.cc: No such file or directory.
> > > >
> > > >         in Splash.cc
> > > >
> > > > Seems to be fairly consistently doing Splash:pipeRun.  I'm not
> familiar
> > > > with the source, and not sure if this is helpful or not, but I'd be
> > > > glad to gather other info upon request.
> > >
> > > A single function doesn't help much, give us a few backtraces.
> >
> > [some backtraces]
>
> By the look of the backtraces and the description of the problem seems
> pretty
> much to be https://bugs.freedesktop.org/show_bug.cgi?id=13518
>
> Of course without you sharing the file it is not possible to make sure.
>

How slow is "slow"?  The example in the bug runs to completion for me in
about 10 seconds on my system.  So far, I've never seen the pdf in my case
even finish.  I will run it over night to see if it does.

I'd appreciate an expert opinion on my situation given this information.
 I'm in charge of a large number of general purpose cups servers.  A pdftops
job running for 2 minutes does not really concern me, but if it's true that
these jobs may last hours or more, it's really going to be a problem for my
systems.  A single job might swamp a smaller server, but if said user tries
to print the document more than once, it may even tie up the cores on larger
servers.  Even if I nice pdftops to lower priority, it's still going to
block up the queues for however long.

I don't claim to know much about the PDF format, and I certainly don't know
the technical hurdles being faced here.  I assume that since the bug has
been open for a few years now, they're significant, and probably won't be
resolved in the near future.  If patterns are the problem, can they just be
disabled?  I'm sure this will alter the printed document, but it's much
easier to explain that to a few users than to justify the servers going down
every couple days.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20110203/1787e181/attachment.html>