Bug 700584

Summary: High RIP_MAX_CACHE makes "cups" output device fail
Product: Ghostscript Reporter: Till Kamppeter <till.kamppeter>
Component: CUPS driverAssignee: Michael Vrhel <michael.vrhel>
Status: RESOLVED FIXED    
Severity: normal CC: htl10, michael.vrhel, mike
Priority: P4    
Version: 9.26   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: appout.pdf
patch

Description Till Kamppeter 2019-02-11 15:52:18 UTC
Created attachment 16878 [details]
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?)?
Comment 1 Till Kamppeter 2019-02-11 15:56:02 UTC
Original bug report to Ubuntu:

https://bugs.launchpad.net/gs-gpl/+bug/1815339
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

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:

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.
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

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