d.scale & d.label crash XDRIVER in Panel_save

[Bob Black]

Paul Loechl wrote:

> I was curious to see if I could duplicate the errors that you experienced
> with d.scale and d.label.  I displayed a map and tried to crash the XDRIVER
> by picking insertion points very close to the boundaries of the map and of
> the graphics monitor.  I tried but could not get the errors that you reported
.
> 
> Can you write back with more information on your setup and version of Grass
> that you are using? 


First I should mention that we're not using a standard GRASS x0-type
monitor.  Instead we're using a customized larger one whose screen
size is 1142 x 870 (which I determined by executing the xwininfo
command).  This always worked fine on our Sun workstations whose
screen size is 1152 x 900.

However, I was recently running on an HP Aptrex X terminal whose size
of 1024 x 768 is smaller than our GRASS monitor.  In this case, calls
in Panel_save to XGetImage will crash the xdriver.  As soon as I
manually reduced the GRASS monitor to fit within the HP screen, the
problem goes away.  That is, it goes away for the d.scale and d.label
commands.

However I still do have a problem with a custom program that, like
d.scale and d.label, initiates actions which cause the xdriver to
invoke the Panel_save() function.  This problem, as above, is this: a
crash occurs when my monitor is in the iconized state.  This crash
occurs because XGetImage returns a NULL when the monitor is iconized.
Then Panel_save(), assuming that a valid pointer was returned, uses
the NULL pointer value to access structure elements.

By not checking the return value from XGetImage, the Panel_save() code
seems a little risky.  Yet, as far as I could tell, such a check is
unnecessary in any current GRASS programs, and thus its omission is
not normally a problem.  It becomes a problem for me because of an
in-house special program that we need to run.

So two solutions come to mind: (1) alter Panel_save() to test the
return value from XGetImage and refuse to save a panel if that return
value is NULL; or (2) add a check on the GRASS application side to see
if the monitor map state value is set to IsViewable...and then only
send a panel save token to the xdriver if this check passes.

The disadvantage of #1 is that we deviate from the standard monitor
code, thus complicating future upgrades.

The disadvantage of #2 is (I think) that we unwisely violate a barrier
by putting X code outside the xdriver, thereby compromising the device
independence.

Any suggestions and comments are welcomed.

- Bob

Robert Black (black at calspan.com) - Principal Engineer
Calspan SRL Corporation - Advanced Technology Center
PO Box 400
Buffalo, NY 14225  USA