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. Albert > > Thanks, > M@ _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
