[poppler] infinite running pdftops

[Albert Astals Cid]

A Divendres, 4 de febrer de 2011, Matt LaPlante va escriure:
> On Fri, Feb 4, 2011 at 2:40 AM, Albert Astals Cid <aacid at kde.org> wrote:
> > 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.
> 
> Are Gfx::doPatternFill and Gfx::doPatternStroke still the correct entry
> points? I patched the source to add a return; to the beginning of both
> functions and performance has not improved. Looking at the backtraces this
> sort of make sense... I don't see either function call showing up in any of
> the traces. I would expect to see them there if they were accounting for
> most of the time used.

Yes they are. If this does not help you, you are on your own since you don't 
want to share the files.

Albert