<br><br><div class="gmail_quote">On Thu, Feb 3, 2011 at 6:20 PM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>A Dijous, 3 de febrer de 2011, Matt LaPlante va escriure:<br>
> 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:<br>
> > A Dijous, 3 de febrer de 2011, Matt LaPlante va escriure:<br>
> > > I occasionally run into cups servers in which pdftops will be running<br>
> > > seemingly forever against a single pdf. Currently we're using 0.16.1.<br>
> > > I would love to be able to provide one of the PDFs in question, but<br>
> > > unfortunately this is a business environment and most of the files are<br>
> > > confidential. I'm hoping there is some other way we can work towards<br>
> > > debugging the situation.<br>
> > ><br>
> > > I have one such pdf sitting in front of me now. The pdftops<br>
> ><br>
> > -origpagesize<br>
> ><br>
> > > -level2 [pdf] just keeps churning and churning. It produced a sizable<br>
> ><br>
> > .ps<br>
> ><br>
> > > file almost immediately, then it just stops writing data, even though<br>
> > > the process is still running. The .ps file never appears to grow,<br>
> > > even if<br>
> ><br>
> > left<br>
> ><br>
> > > for several more minutes. This behavior hangs up cups something awful,<br>
> ><br>
> > but<br>
> ><br>
> > > I can also reproduce it manually.<br>
> > ><br>
> > > I fired up the process in gdb, waited for a few minutes, and then<br>
> > > stopped the process. Each time, the output was:<br>
> > ><br>
> > > 0x00007ffff7b3e254 in Splash::pipeRun (this=<value optimized out>,<br>
> > > pipe=0x7fffffffd350) at Splash.cc:402<br>
> > > 402 Splash.cc: No such file or directory.<br>
> > ><br>
> > > in Splash.cc<br>
> > ><br>
> > > 0x00007ffff7b3e269 in Splash::pipeRun (this=<value optimized out>,<br>
> > > pipe=0x7fffffffd350) at Splash.cc:405<br>
> > > 405 Splash.cc: No such file or directory.<br>
> > ><br>
> > > in Splash.cc<br>
> > ><br>
> > > Splash::pipeRun (this=0x7872d0, pipe=0x7fffffffd350) at Splash.cc:399<br>
> > > 399 Splash.cc: No such file or directory.<br>
> > ><br>
> > > in Splash.cc<br>
> > ><br>
> > > Seems to be fairly consistently doing Splash:pipeRun. I'm not familiar<br>
> > > with the source, and not sure if this is helpful or not, but I'd be<br>
> > > glad to gather other info upon request.<br>
> ><br>
> > A single function doesn't help much, give us a few backtraces.<br>
><br>
</div></div>> [some backtraces]<br>
<br>
By the look of the backtraces and the description of the problem seems pretty<br>
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><br>
<br>
Of course without you sharing the file it is not possible to make sure.<br></blockquote><div><br></div><div>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><br></div><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.</div>
<div><br></div><div>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>
<div><br></div></div>