On Fri, Feb 4, 2011 at 2:40 AM, Albert Astals Cid <[email protected]> wrote:
> A Divendres, 4 de febrer de 2011, Matt LaPlante va escriure: > > On Thu, Feb 3, 2011 at 6:20 PM, Albert Astals Cid <[email protected]> wrote: > > > A Dijous, 3 de febrer de 2011, Matt LaPlante va escriure: > > > > On Thu, Feb 3, 2011 at 5:23 PM, Albert Astals Cid <[email protected]> > 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.
_______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
