[poppler] infinite running pdftops

[Albert Astals Cid]

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@