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

Bug #1815339 reported by Fedik on 2019-02-10
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
GS-GPL
Fix Released
Medium
ghostscript (Ubuntu)
High
Marc Deslauriers
Trusty
Undecided
Marc Deslauriers
Xenial
Undecided
Marc Deslauriers
Bionic
Undecided
Marc Deslauriers
Cosmic
Undecided
Marc Deslauriers
Disco
High
Marc Deslauriers

Bug Description

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) wrote :
tags: added: printing
Fedik (fedikw) wrote :

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

Fedik (fedikw) wrote :

here is a captured print job

Till Kamppeter (till-kamppeter) wrote :

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

Changed in ghostscript (Ubuntu):
status: New → Incomplete
Fedik (fedikw) wrote :

yes, here it is

Till Kamppeter (till-kamppeter) wrote :

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) wrote :

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.

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) wrote :

Reported to Ghostscript upstream as

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

Changed in gs-gpl:
importance: Unknown → Medium
status: Unknown → New

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.

tags: added: regression-update
Changed in ghostscript (Ubuntu):
importance: Undecided → High
status: Incomplete → Triaged

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.

Changed in gs-gpl:
status: New → Unknown

Created attachment 16882
patch

Patch to fix this and Bug 699713

Changed in gs-gpl:
status: Unknown → Fix Released
Changed in ghostscript (Ubuntu Trusty):
status: New → Confirmed
Changed in ghostscript (Ubuntu Xenial):
status: New → Confirmed
Changed in ghostscript (Ubuntu Bionic):
status: New → Confirmed
Changed in ghostscript (Ubuntu Cosmic):
status: New → Confirmed
Changed in ghostscript (Ubuntu Disco):
status: Triaged → Confirmed
Changed in ghostscript (Ubuntu Trusty):
assignee: nobody → Marc Deslauriers (mdeslaur)
Changed in ghostscript (Ubuntu Xenial):
assignee: nobody → Marc Deslauriers (mdeslaur)
Changed in ghostscript (Ubuntu Bionic):
assignee: nobody → Marc Deslauriers (mdeslaur)
Changed in ghostscript (Ubuntu Cosmic):
assignee: nobody → Marc Deslauriers (mdeslaur)
Changed in ghostscript (Ubuntu Disco):
assignee: nobody → Marc Deslauriers (mdeslaur)
Launchpad Janitor (janitor) wrote :

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

Changed in ghostscript (Ubuntu Disco):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in ghostscript (Ubuntu Trusty):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in ghostscript (Ubuntu Xenial):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in ghostscript (Ubuntu Cosmic):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in ghostscript (Ubuntu Bionic):
status: Confirmed → Fix Released

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.

OK. Taking a look at this now.

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

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

Changed in ghostscript (Ubuntu Trusty):
status: Fix Released → Triaged
Changed in ghostscript (Ubuntu Xenial):
status: Fix Released → Triaged
Changed in ghostscript (Ubuntu Bionic):
status: Fix Released → Triaged
Changed in ghostscript (Ubuntu Cosmic):
status: Fix Released → Triaged
Changed in ghostscript (Ubuntu Disco):
status: Fix Released → Triaged
Marc Deslauriers (mdeslaur) wrote :

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) wrote :

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

Changed in ghostscript (Ubuntu Cosmic):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in ghostscript (Ubuntu Xenial):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in ghostscript (Ubuntu Bionic):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in ghostscript (Ubuntu Trusty):
status: Triaged → Fix Released
Marc Deslauriers (mdeslaur) wrote :

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

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

Thanks.

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) wrote :

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

Torsten Landschoff (torsten) wrote :

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!

Changed in ghostscript (Ubuntu Disco):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.