Bug 690428

Same results for a freshly compiled gs 8.64 on suse 11.1 (32bit).

reproduced crash with r11340 (about a month0x00000000006cfd07 in -old svn debug build). Partial backtrace and other info below:


gdev_x_map_rgb_color (dev=0x19bb8e8, cv=0x7fffffffb4c0) at ./base/gdevxcmp.c:686
686			    xdev->cman.dither_ramp[CUBE_INDEX(cr, cg, cb)];
#0  0x00000000006cfd07 in gdev_x_map_rgb_color (dev=0x19bb8e8, cv=0x7fffffffb4c0) at ./base/gdevxcmp.c:686
#1  0x000000000097b0c8 in check_device_separable (dev=0x19bb8e8) at ./base/gdevdflt.c:443
#2  0x00000000006d19bc in gdev_x_open (xdev=0x19bb8e8) at ./base/gdevxini.c:307
#3  0x00000000006c9f84 in x_open (dev=0x19bb8e8) at ./base/gdevx.c:255
#4  0x00000000008e7dd7 in gs_opendevice (dev=0x19bb8e8) at ./base/gsdevice.c:367
....


(gdb) print xdev->cman
$1 = {num_rgb = 256, color_mask = {red = 65280, green = 65280, blue = 65280}, match_mask = {red = 65280, green = 65280, blue = 65280}, std_cmap = {
    map = 0x0, fast = 0, red = {cv_shift = 0, nearest = {0 <repeats 64 times>}, pixel_shift = 0}, green = {cv_shift = 0, nearest = {
        0 <repeats 64 times>}, pixel_shift = 0}, blue = {cv_shift = 0, nearest = {0 <repeats 64 times>}, pixel_shift = 0}, free_map = 0}, 
  color_to_rgb = {size = 256, values = 0x1c5d3f0}, dither_ramp = 0x1c5e030, dynamic = {size = 256, colors = 0x1c5e470, shift = 8, used = 0, 
    max_used = 128}}
(gdb) print xdev->cman.dither_ramp
$2 = (x_pixel *) 0x1c5e030
(gdb) print cr
$3 = 255
(gdb) print cg
$4 = 0
(gdb) print cb
$5 = 0
(gdb) print CUBE_INDEX
No symbol "CUBE_INDEX" in current context.
(gdb) 
----------------
Somehow it is failing to map (255,0,0). (a red color, I suppose)

The crash is fixed in r11455, but it seems that it is not setting the color map of the X server correctly, for dynamic colors (on a color display configured for gray, some colors appears to be red rather than a shade of gray).

Here is a patch which tries to address such problem. colorcir.ps works, but then some colorblocks in contrib/pscolor/*.{ps,pdf} disappears.

Anyway, I'd like to know what sort of X display you have before filing a 2nd bug about the color problem.

--- a/base/gdevxcmp.c
+++ b/base/gdevxcmp.c
@@ -708,6 +708,10 @@ gdev_x_map_rgb_color(gx_device * dev, const gx_color_value cv[])
 	}
     }
 
+    if (xdev->color_info.num_components == 1) {
+      dg = db = dr;
+    }
+
     /* Finally look through the list of dynamic colors */
     if (xdev->cman.dynamic.colors) {
 	int i = (dr ^ dg ^ db) >> xdev->cman.dynamic.shift;

r11455 reverted for it being wrong. 
re-assign to DeviceN person to review new patch.

The color problem  mentioned in comment 3 is filed as bug 691432 and still happens with the new patch.

Created attachment 6423 [details]
setting gray_index to zero for gray/monochrom displays

This is a more correct patch to cope with the DeviceN change r2925 which happened 8 years ago.

Applied the attached patch as SVN rev. 11558.

(In reply to Hin-Tak Leung from comment #3)
...
> --- a/base/gdevxcmp.c
> +++ b/base/gdevxcmp.c
> @@ -708,6 +708,10 @@ gdev_x_map_rgb_color(gx_device * dev, const
> gx_color_value cv[])
>  	}
>      }
>  
> +    if (xdev->color_info.num_components == 1) {
> +      dg = db = dr;
> +    }
> +
>      /* Finally look through the list of dynamic colors */
>      if (xdev->cman.dynamic.colors) {
>  	int i = (dr ^ dg ^ db) >> xdev->cman.dynamic.shift;

Interesting enough, looking at that old post, that hack was actually about 1/3 of my final fix, and now I have a good explanation of why it worked a bit, and what else is needed to:

details:
http://bugs.ghostscript.com/show_bug.cgi?id=691432#c8

patch itself
http://bugs.ghostscript.com/attachment.cgi?id=11680&action=diff