Hide Forgot
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): ghostscript-7.05-32.1 (but Fedora's 7.07-17 has exactly the same bug) How reproducible: Always 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 Actual results: Segmentation fault Expected results: I'd expect a proper cups raster file or an error message if the parameter is incorrect (I believe it is correct). Additional info: 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 inside ghostscript. 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 raster. It looks it's impossible to generate any CMYK page as a cups raster file. 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.