[GRASS-dev] Re: problem with G_fatal_error

[Glynn Clements]

Markus Neteler wrote:

> here a request from the QGIS team... please group reply since
> Martin isn't subscribed.
> 
> thanks
> Markus
> 
> On Mon, Oct 22, 2007 at 11:04:30AM +0200, Martin Dobias wrote:
> > Hi Markus,
> > 
> > I'm currently working with Leonardo Lami on a crash in QGIS when user
> > tries to open corrupted vector layer. We've found out that it's a
> > regression from grass 6.2 and the problem happens only in 6.3.cvs.
> > 
> > The problem looks like this: QGIS calls Vect_open_old_head function -
> > that one finds out that the layer is corrupted and calls G_fatal_error
> > routine. Looking at that function I see that in 6.3.cvs the function
> > always calls exit() which is incorrect, because this takes also the
> > whole QGIS down. GRASS 6.2 has a condition "if ( ext_error ) return
> > 0;" before the exit statement, so since QGIS sets extended error
> > handler, everything is okay. Please could you add that condition back?

No.

Code which calls G_fatal_error() is entitled to assume (and normally
does assume) that G_fatal_error() will not return.

If you don't want G_fatal_error() to terminate the process, you need
to ensure that your fatal error handler doesn't return, but e.g. 
longjmp()s back to your code.

You will need to bear in mind that any variables used by the GRASS
libraries will be in an undefined state after this point, so the
effect of calling any GRASS function is undefined.

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