Ghostscript and ghostscript-cups were updated this afternoon. Backing out fixed our issue.


We are send ps2pdf and received the following.


D [07/May/2019:13:16:23 -0400] [Job 44895] PID 56104 (/usr/lib/cups/filter/pstopdf) exited with no errors.
D [07/May/2019:13:16:23 -0400] [Job 44895] Filetype: PDF
D [07/May/2019:13:16:23 -0400] [Job 44895] Storing temporary files in /var/spool/cups/tmp
D [07/May/2019:13:16:23 -0400] [Job 44895] PID 56105 (/usr/lib/cups/filter/pdftopdf) exited with no errors.
D [07/May/2019:13:16:23 -0400] [Job 44895] GPL Ghostscript 9.07: Unrecoverable error, exit code 1
D [07/May/2019:13:16:23 -0400] [Job 44895] Process is dying with "Unable to determine number of pages, page count: -1
D [07/May/2019:13:16:23 -0400] [Job 44895] ", exit stat 3
D [07/May/2019:13:16:23 -0400] [Job 44895] Cleaning up...
D [07/May/2019:13:16:23 -0400] [Job 44895] PID 56106 (/usr/lib/cups/filter/foomatic-rip) stopped with status 3.

Hello Art,

thank you for reporting this problem!

Please, may I ask you to share with us:

1. the ghostscript version you updated to which introduced the problem
2. the last working version
3. and also to attach the document on which it failed? (so that I can try to reproduce and investigate further)

Thank you and regards,
-Martin

I am also seeing this problem.  Attempts to print result in a "Filter failed" message in /var/log/cups/error_log.  Printing was functional prior to a vacation I took during the first two weeks of May.  I did a yum update after I returned, and now printing is broken.  The install date shown for ghostscript is Thu 16 May 2019 08:05:28 AM PDT.

Perhaps this is same problem as described in this Arch bug report.
<https://bugs.archlinux.org/task/62251>

My speculation is that this is due to the recent ghostscript update.  I think Redhat back-ported a ghostscript security fix that is causing a failure in the cups filters.  cups-filters likely needs the same fix that was applied by Arch.

Here are the current versions of these packages on my machine.
ghostscript-9.07-31.el7_6.11.x86_64
cups-filters-1.0.35-22.el7.x86_64


galen

cups-filters was apparently using an undocumented feature of Ghostscript to count pages in PDFs - a feature that has been removed.  As a result, printing seems to be pretty much completely broken for any job that needs to go through a filter.

Debian bug - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926576
Arch bug - https://bugs.archlinux.org/task/62251
Upstream commit to fix - https://github.com/OpenPrinting/cups-filters/commit/297cc2decc53e0b08eb03049fce375db33df2131

ghostscript/ghostscript-cups 9.07-31.el7_6.10 work.  9.07-31.el7_6.11 does not.

Clearing NEEDINFO, as I have provided the requested version information.

Hi everyone,

would anyone mind providing me following info:

1) how do you issue printing to trigger the issue? (by lp command or from which application)
2) please attach the file you are trying to print, ppd file of your print queue (it is in /etc/cups/ppd with <name_of_your_print_queue>.ppd) and the latest file from /var/spool/cups directory (with 'd' at the beginning of name) 
3) please gather the output of 'sudo lpinfo -l -v' and 'lpstat -t' into file

I was not able to reproduce the issue so far :(

Created attachment 1572079 [details]
File being printed

Created attachment 1572080 [details]
PPD file

Created attachment 1572081 [details]
CUPS spool file

Created attachment 1572082 [details]
Output of 'lpinfo -l -v'

Created attachment 1572083 [details]
Output of 'lpstat -t'

(In reply to Zdenek Dohnal from comment #9)
> 1) how do you issue printing to trigger the issue? (by lp command or from
> which application)

I can trigger the issue with 'lp -d e210 game.pdf'

> 2) please attach the file you are trying to print, ppd file of your print
> queue (it is in /etc/cups/ppd with <name_of_your_print_queue>.ppd) and the
> latest file from /var/spool/cups directory (with 'd' at the beginning of
> name) 
> 3) please gather the output of 'sudo lpinfo -l -v' and 'lpstat -t' into file

Files attached

Just getting started here on the west coast.  Looks like Ian has already supplied the necessary info.  Anyway, confirming what is shown the Arch bug report, here is a before and after.  If cups-filters is using pdfdict, then this shows the problem.

On a laptop that still has an older ghostscript rpm:
galens@tinman:~$ rpm -q ghostscript
ghostscript-9.07-31.el7_6.9.x86_64
galens@tinman:~$ gs -dNODISPLAY -q -c '/pdffile (/usr/share/cups/data/default-testpage.pdf) (r) file def pdfdict begin pdffile pdfopen begin (PageCount: ) print pdfpagecount == flush currentdict pdfclose end end quit'
PageCount: 1


On my desktop machine with the latest ghostscript rpm:
[galens@toto ~]$ rpm -q ghostscript
ghostscript-9.07-31.el7_6.11.x86_64
[galens@toto ~]$ gs -dNODISPLAY -q -c '/pdffile (/usr/share/cups/data/default-testpage.pdf) (r) file def pdfdict begin pdffile pdfopen begin (PageCount: ) print pdfpagecount == flush currentdict pdfclose end end quit'
Error: /undefined in pdfdict
Operand stack:

Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:938/1684(ro)(G)--   --dict:0/20(G)--   --dict:77/200(L)--
Current allocation mode is local
GPL Ghostscript 9.07: Unrecoverable error, exit code 1

I was able to reproduce the issue with Ian's ppd file and socket backend. I'll write the test for the issue.

Confirmed the upstream patch fixed the issue.

Created attachment 1572594 [details]
Patch

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2337