[GRASS-dev] GRASS & QGIS: the future

[Glynn Clements]

Radim Blazek wrote:

> > Also, currently the global error handler (G_set_error_routine) is
> > called before the non-exclusive handlers (G_add_error_handler), so
> > those will never be called if the global handler lonjmp()s out. The
> > global error handler isn't limited to fatal errors, but is also used
> > for messages and warnings.
> 
> G_add_error_handler() is used by GRASS itself?

The raster library installs a handler which calls Rast__unopen_all(). 
The vector and DBMI libraries provide interfaces to it, although I
don't know how (or if) these are used at present.

> > Perhaps we need a dedicated fatal error handler for this purpose? It
> > would be called immediately prior to the final exit() call. It would
> > not be allowed to call GRASS functions or to return. The busy flag
> > could be cleared before calling it.
> 
> Whatever allows to "recover" from fatal error will help. I would prefer
> however not changing semantics too much so that GRASS 6, 7.0.0beta1 and
> 7.x.x may be easily supported by the same code with only few ifdefs.

7.x doesn't aim for compatibility with 6.x.

I'd suggest resolving this prior to any 7.0 pre-release/beta/RC.

Currently, lonjmp()ing out of a handler registered with
G_set_error_routine() will skip any handlers registered with
G_add_error_handler().

Another option is to change GRASS_SIGSEGV_ON_ERROR to call abort()
(i.e. raise SIGABRT rather than SIGSEGV), then code can install a
signal handler for SIGABRT and siglongjmp() out of that (installing a
handler for SIGSEGV is unwise, as you can't easily distinguish a
raise()d SIGSEGV from one caused by e.g. memory corruption).

Actually, I'm going to make that change regardless. Whether this is
sufficient or whether we still need a dedicated "termination handler"
remains open for discussion.

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