<div class="gmail_quote">On Fri, Feb 4, 2011 at 2:40 AM, Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> A Divendres, 4 de febrer de 2011, Matt LaPlante va escriure: <div><div></div><div>> On Thu, Feb 3, 2011 at 6:20 PM, Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> wrote: > > A Dijous, 3 de febrer de 2011, Matt LaPlante va escriure: > > > On Thu, Feb 3, 2011 at 5:23 PM, Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> 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 <a href="https://bugs.freedesktop.org/show_bug.cgi?id=13518" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=13518</a> > > > > 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. </div></div>Slow as in hours. <div> > > 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. </div>You can disable them in your copy if you want, the bug explains how to do that. </blockquote><div> </div><div>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.</div> <div> </div></div>