[poppler] infinite running pdftops

[Albert Astals Cid]

A Divendres, 4 de febrer de 2011, Matt LaPlante va escriure:
> 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.

Slow as in hours.

> 
> 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.

You can disable them in your copy if you want, the bug explains how to do 
that.

Albert