Bug 690428 - gs crashes for x11 resource "Ghostscript*palette: GrayScale"
Summary: gs crashes for x11 resource "Ghostscript*palette: GrayScale"
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: X Display Driver (show other bugs)
Version: 8.62
Hardware: PC Linux
: P4 normal
Assignee: Henry Stiles
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-18 08:55 UTC by Stephan Wefing
Modified: 2015-05-13 13:07 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
setting gray_index to zero for gray/monochrom displays (892 bytes, patch)
2010-07-02 00:18 UTC, Hin-Tak Leung
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Wefing 2009-04-18 08:55:01 UTC
how to reproduce:
- add the line "Ghostscript*palette: GrayScale" to ~/.Xdefaults
- activate the new resource by calling "xrdb -merge ~/.Xdefaults"
- call gs without any arguments -> segmentation fault

My os is suse 11.1 (32bit).

As a consequence (my guess), "ghostview --grayscale" and "gv --grayscale" do
not work either (the corresponding gs subprocess crashes). the "--grayscale"
option does not work on suse 10.3 (64bit, gs 8.15.4) and knoppix 6.21 (32bit,
gs 8.63) either. it does work, however, on an ancient suse 9.2 (32 bit, gs
7.07.1).
Comment 1 Stephan Wefing 2009-04-18 15:30:32 UTC
Same results for a freshly compiled gs 8.64 on suse 11.1 (32bit).
Comment 2 Hin-Tak Leung 2010-06-26 23:55:30 UTC
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)
Comment 3 Hin-Tak Leung 2010-06-29 06:56:17 UTC
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;
Comment 4 Hin-Tak Leung 2010-07-02 00:15:10 UTC
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.
Comment 5 Hin-Tak Leung 2010-07-02 00:18:18 UTC
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.
Comment 6 Till Kamppeter 2010-07-30 10:11:22 UTC
Applied the attached patch as SVN rev. 11558.
Comment 7 Hin-Tak Leung 2015-05-13 13:07:12 UTC
(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