[GRASS-user] The tomcat shut down when encounter some error grass commond

Glynn Clements glynn at gclements.plus.com
Tue Sep 22 17:22:38 EDT 2009


Sören Gebbert wrote:

> > Finally, although you can override the fatal error handler with
> > G_set_error_routine(), the supplied handler mustn't return, and you
> > cannot safely use any GRASS functions once a fatal error has been
> > detected, as the data structures used by the libraries will be in an
> > undefined state.
> 
> Well, thats exactly the problem that i face with grass trying to run several
> operations within on process using the vtkGRASSBridge.
> Is there any chance to implement a conterpart to G_init() like G_uninit()
> to compute several tasks in one process (not multithreaded).
> 
> Is there really no way to reset the static variables to initial state?

The variables are littered throughout the various source files of the
various libraries, and initialisation upon first use is a common idiom
in GRASS.

You would need to identify all of the relevant variables, make them
non-"static", and add a function to reset them. You would need a
separate reset function for each library. And you would need to keep
track of any new variables which were added (don't rely upon
developers co-operating; I've had trouble implementing "no static
data" policies even on projects which were generally well-organised).

Oh; and some of the libraries which GRASS uses may have their own
static data, so you would have to figure out how to reset those
libraries.

For lib/gis and and lib/raster, searching for "struct state" (in 7.0)
will find many of them. Beyond that, searching the output from "nm"
for symbols of type B, D, b and d will show static variables (some of
which never change, but aren't in the rodata segment because adding
the "const" qualifier introduces compatibility issues).

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-user mailing list