Bug 700584 - High RIP_MAX_CACHE makes "cups" output device fail
Summary: High RIP_MAX_CACHE makes "cups" output device fail
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: CUPS driver (show other bugs)
Version: 9.26
Hardware: PC Linux
: P4 normal
Assignee: Michael Vrhel
QA Contact: Bug traffic
Depends on:
Reported: 2019-02-11 15:52 UTC by Till Kamppeter
Modified: 2019-02-22 22:14 UTC (History)
3 users (show)

See Also:
Word Size: ---

appout.pdf (25.63 KB, application/pdf)
2019-02-11 15:52 UTC, Till Kamppeter
patch (2.65 KB, text/plain)
2019-02-13 20:04 UTC, Michael Vrhel

Note You need to log in before you can comment on or make changes to this bug.
Description Till Kamppeter 2019-02-11 15:52:18 UTC
Created attachment 16878 [details]

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?)?
Comment 1 Till Kamppeter 2019-02-11 15:56:02 UTC
Original bug report to Ubuntu:

Comment 2 Chris Liddell (chrisl) 2019-02-11 18:45:44 UTC
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.
Comment 3 Michael Vrhel 2019-02-13 20:04:14 UTC
Created attachment 16882 [details]

Patch to fix this and Bug 699713
Comment 5 Till Kamppeter 2019-02-22 12:59:01 UTC
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:


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

I will ask the user for further information.
Comment 6 Michael Vrhel 2019-02-22 16:22:27 UTC
OK.  Taking a look at this now.
Comment 7 Michael Vrhel 2019-02-22 18:06:14 UTC
OK.  I do see the blue background for the output with -dcupsColorSpace=17 (RGBW colorspace ) using Mike Sweet's rasterview program.
Comment 8 Michael Vrhel 2019-02-22 22:14:08 UTC
The issue with the RGBW color space should be resolved with