Red Hat Bugzilla – Bug 114256
Ghostscript coredumps when trying to generate cups raster with more than 1 bit per color
Last modified: 2007-04-18 13:02:10 EDT
Description of problem:
gs barfs with signal 11 if trying to use a device CUPS
with BitsPerColor > 1.
Version-Release number of selected component (if applicable):
(but Fedora's 7.07-17 has exactly the same bug)
Steps to Reproduce:
1. gs -sDEVICE=cups -dcupsBitsPerColor=8
2. or, if you you want to be 100% correct
3. gs -sDEVICE=cups -dcupsBitsPerColor=8 -sOutputFile=file.cups anyfile.ps
I'd expect a proper cups raster file or an error message if the
parameter is incorrect (I believe it is correct).
The bug seems to be somewhere gdev_prn_allocate() but I'm not
sure, I was not able to trace it. Ghostscript C code contains
too many macros to trace.
The reallocation fails because it thinks the old base address is 0 for
some reason -- you're right, it's hard to figure out what's going on
To get an idea of the severity of this problem can you tell me how you
came across it? Thanks.
We have a color printer -- Phaser 8200DP. It contains a bug in
its PostScript interpreter that hangs the whole printer sometimes.
We need to find a way around. We tried to generate a CMYK
pixel-mapped page in cups format because it is easy to
interpret -- there is a library in cups-devel and there is
a trivial way to make a "<<dict>>image ...pixmap" from such
It looks it's impossible to generate any CMYK page as a cups
I don't know the severity, but I think the problem occurs during
rendering cups color pages, even those for simple inkjet printers.
As far as I know from cups manual page cups raster file, a.k.a
-sDEVICE=cups is supposed to be an universal raster file. It is
supposed to be converted to the final printer format.
I think this might be fixed (or at least worked around) in 7.07-19, by
changing the 'reallocate' to 'allocate' in gdevcups.c.