Printer stopped printing paper size 4"x6" after update ghostscript to 9.26

[Fedik]

I have an issue with Ghostscript and printing.
I use Gutenprint for my Canon MG5440, and I cannot print a photo 4"x6" (or 6"x4"), it does not print anything, however I still able to print A4 paper size.
I use Ubuntu 18.04 and Gutenprint 5.3.1.

The printing fail with message:
....
[Job 143] Start rendering...
[Job 143] Processing page 1...
[Job 143] **** Unable to open the initial device, quitting.
[Job 143] Rendering completed
...
[Job 143] PID 24869 (/usr/lib/cups/filter/gstoraster) stopped with status 1.
...
[Job 143] printer-state-message="Filter failed"
[Job 143] printer-state-reasons=none

The message "Unable to open the initial device, quitting" comes from Ghostscript.

When I downgrade Ghostscript to 9.22,
I am again able to print 4"x6" paper size.

To downgrade: apt install ghostscript=9.22~dfsg+1-0ubuntu1 libgs9=9.22~dfsg+1-0ubuntu1 libgs9-common=9.22~dfsg+1-0ubuntu1

I found similar issue for HP printer at Debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908205

System info:
Description: Ubuntu 18.04.1 LTS
Release: 18.04

ghostscript:
  Installed: 9.26~dfsg+0-0ubuntu0.18.04.4
  Candidate: 9.26~dfsg+0-0ubuntu0.18.04.4
  Versions:
 *** 9.26~dfsg+0-0ubuntu0.18.04.4 500
        500 http://ua.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
        100 /var/lib/dpkg/status
     9.22~dfsg+1-0ubuntu1 500
        500 http://ua.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

cups:
  Installed: 2.2.7-1ubuntu2.3
  Candidate: 2.2.7-1ubuntu2.3
  Versions:
 *** 2.2.7-1ubuntu2.3 500
        500 http://ua.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.2.7-1ubuntu2.2 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
     2.2.7-1ubuntu2 500
        500 http://ua.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

[Fedik (fedikw)]

Additional, if I run a raw GS command, Ghostscript does not crashes.

gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sOutputFile=foo.bar -sDEVICE=cups -sMediaClass=Cassette -sMediaType=PhotopaperMatte -r600x600 -dDEVICEWIDTHPOINTS=288 -dDEVICEHEIGHTPOINTS=432 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=6 -dcupsCompression=7 -dcupsRowFeed=2 -scupsPageSizeName=w288h432 -I/usr/share/cups/fonts -c '<</.HWMargins[0.000000 0.000000 0.000000 0.000000] /Margins[0 0]>>setpagedevice' -f samplec.ps

[Robert Krawitz (rlk-alum)]

Reference https://sourceforge.net/p/gimp-print/bugs/719/

[Fedik (fedikw)]

here is a captured print job

[Till Kamppeter (till-kamppeter)]

Fedik, can you please attach the PPD file of your print queue (from the /etc/cups/ppd/) directory? Thanks.

[Fedik (fedikw)]

yes, here it is

[Till Kamppeter (till-kamppeter)]

Thanks for the PPD file (and the job captured from the app). Now I can reproduce the crash with

cupsfilter -p MG5400LAN-Gutenprint.ppd -o PageSize=w288h432 -m application/vnd.cups-raster appout.pdf > out.prn

out.prn is empty. Nothing has been written to it when the crash happened.

[Till Kamppeter (till-kamppeter)]

Here is a reproducer (with GS 9.26) consisting in a pure Ghostscript command line:

cat appout.pdf | RIP_MAX_CACHE=128m gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout='%stderr' -sOutputFile='%stdout' -sDEVICE=cups -sMediaClass=Cassette -sMediaType=Plain -r600x600 -dDEVICEWIDTHPOINTS=288 -dDEVICEHEIGHTPOINTS=432 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=6 -dcupsRowFeed=2 -scupsPageSizeName=w288h432 -I/usr/share/cups/fonts -c '<</.HWMargins[0.000000 0.000000 0.000000 0.000000] /Margins[0 0]>>setpagedevice' -f -_ > out.raster

Whether it crashes or not depends on the numeric value of the RIP_MAX_CACHE environment variable. For me all values up to 32.986m succeed and 32.987m and higher fails. Not supplying the RIP_MAX_CACHE also succeeds which is the reason whether the first attempts to run Ghostscript on the command line have succeeded.

Strange is that low values of RIP_MAX_CACHE succeed and high values fail, so it does not seem to be a problem of too small memory.

[Till Kamppeter (till-kamppeter)]

Created attachment 16878
appout.pdf

The problem is that with a certain PDF file (appout.pdf, attached) and certain parameters Ghostscript 9.26 fails when specifying a high value of the RIP_MAX_CACHE environment variable but succeeds when specifying a lower value or no RIP_MAX_CACHE at all. The problem does not occur with Ghostscript 9.22 though.

Here is a reproducer command line:

cat appout.pdf | RIP_MAX_CACHE=128m gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout='%stderr' -sOutputFile='%stdout' -sDEVICE=cups -sMediaClass=Cassette -sMediaType=Plain -r600x600 -dDEVICEWIDTHPOINTS=288 -dDEVICEHEIGHTPOINTS=432 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=6 -dcupsRowFeed=2 -scupsPageSizeName=w288h432 -I/usr/share/cups/fonts -c '<</.HWMargins[0.000000 0.000000 0.000000 0.000000] /Margins[0 0]>>setpagedevice' -f -_ > out.raster

Whether it fails or not depends on the numeric value of the RIP_MAX_CACHE environment variable. For me all values up to 32.986m succeed and 32.987m and higher fails. Not supplying the RIP_MAX_CACHE also succeeds which is the reason whether the first attempts to run Ghostscript on the command line have succeeded.

Strange is that low values of RIP_MAX_CACHE succeed and high values fail, so it does not seem to be a problem of too small memory.

cups/gdevcups.c reads RIP_MAX_CACHE in the cups_get_space_params() function and drops the specified memory size in a gdev_prn_space_params data structure, in both MaxBitMap and BufferSpace fields. And it does this only if the RIP_MAX_CACHE variable exists and has a valid value (non-zero float number with unit k, m, or g). AFAIK it is only used in the "cups" output device, so in all other devices Ghostscript seems to handle MaxBitMap and BufferSpace by itself.

Question is here not only what is going wrong but also whether Ghostscript is perhaps better in setting these sizes by itself and so should we perhaps drop the RIP_MAX_CACHE variable altogether (remove the support for it in cups/gdevcups.c?, set its default in CUPS to the invalid value 0?)?

[Till Kamppeter (till-kamppeter)]

Reported to Ghostscript upstream as

https://bugs.ghostscript.com/show_bug.cgi?id=700584

[Till Kamppeter (till-kamppeter)]

Original bug report to Ubuntu:

https://bugs.launchpad.net/gs-gpl/+bug/1815339

[Chris-liddell (chris-liddell)]

The problem is not really to do with the memory available.

Because of the way the cups device can change color space, and uses "non-standard" color spaces, we have it claim to be a DeviceN device, so ICC profile validation doesn't error out. But that, as it turns out, ends up with trying to use a default DeviceN fill_rectangle method (which returns an error, because of the nature of DeviceN we can't really provide a functional default implementation).

That's what happens with RIP_MAX_CACHE = 128

Using smaller memory size, we go through the clist, and that creates a 32 bit memory device to render the bands, hence bypasses the above problem.

I'll need to discuss this with Michael.

[Till Kamppeter (till-kamppeter)]

The best solution here is a proper fix by Ghostscript's upstream developers. For the case that this fix will not appear soon, the workaround would be to patch CUPS to supply RIP_MAX_CACHE=0 instead of RIP_MAX_CACHE=128m, so that Ghostscript decides on cache sizes by itself.

[Michael-vrhel (michael-vrhel)]

Created attachment 16882
patch

Patch to fix this and Bug 699713

[Michael-vrhel (michael-vrhel)]

Fixed with

http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ba2043a548559d184cbfe90ca9884734dba6efdc

[Launchpad Janitor (janitor)]

This bug was fixed in the package ghostscript - 9.26~dfsg+0-0ubuntu5

---------------
ghostscript (9.26~dfsg+0-0ubuntu5) disco; urgency=medium

  * SECURITY REGRESSION: High RIP_MAX_CACHE makes cups output device fail
    (LP: #1815339)
    - debian/patches/lp1815339.patch: fix logic in cups/gdevcups.c.

 -- Marc Deslauriers <email address hidden> Wed, 20 Feb 2019 10:37:16 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package ghostscript - 9.26~dfsg+0-0ubuntu0.14.04.5

---------------
ghostscript (9.26~dfsg+0-0ubuntu0.14.04.5) trusty-security; urgency=medium

  * SECURITY REGRESSION: High RIP_MAX_CACHE makes cups output device fail
    (LP: #1815339)
    - debian/patches/lp1815339.patch: fix logic in cups/gdevcups.c.
  * debian/symbols.common: add new symbol missing in previous update.

 -- Marc Deslauriers <email address hidden> Wed, 20 Feb 2019 11:46:54 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package ghostscript - 9.26~dfsg+0-0ubuntu0.16.04.5

---------------
ghostscript (9.26~dfsg+0-0ubuntu0.16.04.5) xenial-security; urgency=medium

  * SECURITY REGRESSION: High RIP_MAX_CACHE makes cups output device fail
    (LP: #1815339)
    - debian/patches/lp1815339.patch: fix logic in cups/gdevcups.c.
  * debian/symbols.common: add new symbol missing in previous update.

 -- Marc Deslauriers <email address hidden> Wed, 20 Feb 2019 11:46:24 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package ghostscript - 9.26~dfsg+0-0ubuntu0.18.10.5

---------------
ghostscript (9.26~dfsg+0-0ubuntu0.18.10.5) cosmic-security; urgency=medium

  * SECURITY REGRESSION: High RIP_MAX_CACHE makes cups output device fail
    (LP: #1815339)
    - debian/patches/lp1815339.patch: fix logic in cups/gdevcups.c.
  * debian/libgs9.symbols: add new symbol missing in previous update.

 -- Marc Deslauriers <email address hidden> Wed, 20 Feb 2019 11:45:19 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package ghostscript - 9.26~dfsg+0-0ubuntu0.18.04.5

---------------
ghostscript (9.26~dfsg+0-0ubuntu0.18.04.5) bionic-security; urgency=medium

  * SECURITY REGRESSION: High RIP_MAX_CACHE makes cups output device fail
    (LP: #1815339)
    - debian/patches/lp1815339.patch: fix logic in cups/gdevcups.c.
  * debian/libgs9.symbols: add new symbol missing in previous update.

 -- Marc Deslauriers <email address hidden> Wed, 20 Feb 2019 11:45:50 +0100

[Till Kamppeter (till-kamppeter)]

The Ubuntu security team has applied the fix for this bug to the GhostScript 9.26 which they have issued as security update to several Ubuntu versions.

Unfortunately, this fix has caused a regression. It was reported here:

https://bugs.launchpad.net/bugs/1817308

The user tells that all pages come out with a blue background now.

I will ask the user for further information.

[Michael-vrhel (michael-vrhel)]

OK. Taking a look at this now.

[Michael-vrhel (michael-vrhel)]

OK. I do see the blue background for the output with -dcupsColorSpace=17 (RGBW colorspace ) using Mike Sweet's rasterview program.

[Michael-vrhel (michael-vrhel)]

The issue with the RGBW color space should be resolved with

http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=1bc4205dca71ca075af6ca95aa53a33f5a724586

[Till Kamppeter (till-kamppeter)]

The fix for this bug got reverted as it caused a regression, bug 1817308. Therefore I am re-opening this bug.

A solution for this regression got already committed by the upstream developers of Ghostscript, see the upstream bug report:

http://bugs.ghostscript.com/show_bug.cgi?id=700584

[Marc Deslauriers (mdeslaur)]

Hi everyone,

I would like to re-introduce the fix for this issue in the gostscript package now that upstream has fixed the blue page regression (See bug 1817308).

Unfortunately, I don't know how to test if the issue will come back, as none of my printers were printing a blue page after the original update.

Could someone please test the new ghostscript packages in the security team PPA, available here:

https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages

Please update this bug if you do so that I can release them.

Thanks!

[Launchpad Janitor (janitor)]

This bug was fixed in the package ghostscript - 9.26~dfsg+0-0ubuntu0.18.10.7

---------------
ghostscript (9.26~dfsg+0-0ubuntu0.18.10.7) cosmic-security; urgency=medium

  * SECURITY REGRESSION: High RIP_MAX_CACHE makes cups output device fail,
    second fix attempt. (LP: #1815339)
    - debian/patches/lp1815339.patch: re-enable.
    - debian/patches/lp1815339-2.patch: properly map RGBW color space in
      cups/gdevcups.c.

 -- Marc Deslauriers <email address hidden> Mon, 25 Feb 2019 09:38:22 -0500

[Launchpad Janitor (janitor)]

This bug was fixed in the package ghostscript - 9.26~dfsg+0-0ubuntu0.16.04.7

---------------
ghostscript (9.26~dfsg+0-0ubuntu0.16.04.7) xenial-security; urgency=medium

  * SECURITY REGRESSION: High RIP_MAX_CACHE makes cups output device fail,
    second fix attempt. (LP: #1815339)
    - debian/patches/lp1815339.patch: re-enable.
    - debian/patches/lp1815339-2.patch: properly map RGBW color space in
      cups/gdevcups.c.

 -- Marc Deslauriers <email address hidden> Mon, 25 Feb 2019 09:40:51 -0500

[Launchpad Janitor (janitor)]

This bug was fixed in the package ghostscript - 9.26~dfsg+0-0ubuntu0.18.04.7

---------------
ghostscript (9.26~dfsg+0-0ubuntu0.18.04.7) bionic-security; urgency=medium

  * SECURITY REGRESSION: High RIP_MAX_CACHE makes cups output device fail,
    second fix attempt. (LP: #1815339)
    - debian/patches/lp1815339.patch: re-enable.
    - debian/patches/lp1815339-2.patch: properly map RGBW color space in
      cups/gdevcups.c.

 -- Marc Deslauriers <email address hidden> Mon, 25 Feb 2019 09:40:07 -0500

[Launchpad Janitor (janitor)]

This bug was fixed in the package ghostscript - 9.26~dfsg+0-0ubuntu0.14.04.7

---------------
ghostscript (9.26~dfsg+0-0ubuntu0.14.04.7) trusty-security; urgency=medium

  * SECURITY REGRESSION: High RIP_MAX_CACHE makes cups output device fail,
    second fix attempt. (LP: #1815339)
    - debian/patches/lp1815339.patch: re-enable.
    - debian/patches/lp1815339-2.patch: properly map RGBW color space in
      cups/gdevcups.c.

 -- Marc Deslauriers <email address hidden> Mon, 25 Feb 2019 09:41:28 -0500

[Marc Deslauriers (mdeslaur)]

I have found a way to test the new updates, and have released them:

https://usn.ubuntu.com/3866-3/

Thanks.

[Till Kamppeter (till-kamppeter)]

Marc, I am on Disco and after a system update today I have the following Ghostscript:

----------
ghostscript (9.26~dfsg+0-0ubuntu5) disco; urgency=medium

  * SECURITY REGRESSION: High RIP_MAX_CACHE makes cups output device fail
    (LP: #1815339)
    - debian/patches/lp1815339.patch: fix logic in cups/gdevcups.c.

 -- Marc Deslauriers <email address hidden> Wed, 20 Feb 2019 10:37:16 +0100
----------

For me this looks like the buggy version which causes blue backgrounds on some HP printers.

I by myself could not test it as my HP OfficeJet Pro 8730 uses standard RGB (1) and not RGBW (17) when using the hpcups driver.

As you have uploaded this Ghostscript version, could you also upload the one with the final fix to Disco? Thanks.

[Marc Deslauriers (mdeslaur)]

I uploaded it to disco on Monday, it's stuck in disco-proposed.

[Torsten Landschoff (torsten)]

Printing to our HP 8620 printer was affected by this and can confirm that it is fixed in 9.26~dfsg+0-0ubuntu0.18.04.7 (on xenial).

Thanks for the quick fix!

[Skippy le Grand Gourou (lecotegougdelaforce)]

FWIW, for distributions which haven't published the fix yet (e.g. Slackware AFAICS), RIP_MAX_CACHE can be overwritten by adding this line to cupsd.conf (also editable through CUPS web interface on localhost:631) :

    RIPCache 0

(replace 0 by whatever suits for you).