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@calspan.com) - Principal Engineer
Calspan SRL Corporation - Advanced Technology Center
PO Box 400
Buffalo, NY 14225 USA