[poppler] infinite running pdftops

[Matt LaPlante]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20110204/1206ef1b/attachment.html>