A Divendres, 4 de febrer de 2011, Matt LaPlante va escriure: > 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.
Yes they are. If this does not help you, you are on your own since you don't want to share the files. Albert _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
