[GRASS-dev] [Qgis-developer] GRASS & QGIS: the future

[Radim Blazek]

On Wed, Apr 23, 2014 at 4:02 PM, Sören Gebbert
>> Vector lib does not call G_fatal_error(), it was written in parallel
>> with QGIS plugin with vector editing in mind. I hope it is still true.
>
> I fear that might be not the case anymore. For example, all memory
> allocation functions G_calloc(), G_malloc() and G_realloc() will call
> G_fatal_error() in case the memory allocation fails. As far as i can
> tell the vector library make often use of this functions. So we have
> the problem that basic core functions call G_fatal_error() that are
> used all over the place in GRASS GIS.

I don't care about allocation error. If it really runs out of memory
then exit() is maybe the best. Any other action (saving project,
saving changes) will also need memory and thus fail. Are you often
running out of memory?

It made me curious how Qt handles allocation problem, because I think
that allocation results are not checked in the whole QGIS at all. For
example QString::realloc(int) on the pointer returned by malloc()
calls Q_CHECK_PTR() macro which prints error if pointer is 0. Then it
continues execution even if allocation failed.

> If you patch GRASS to use setjmp/longjmp to implement an exception
> like behavior then you need to write clean up code for static
> variables and dynamically allocated memory. A G_fatal_error() call can
> be deeply nested in a library function. Cleaning only the static
> variables to be in usable state will lead to problematic memory leaks.
> So it is a complex task in GRASS.

I don't want to patch GRASS until it is really inevitable. The next
one is my choice:

> Using setjmp/longjmp in QGIS wrapping all GRASS functions that might
> call G_fatal_error() is complex, since a G_fatal_error() call can be
> deeply nested in a library function. You need to keep track of this
> resulting in plenty setjmp wrappers around GRASS functions.

setjmp will be called just before the top level function we need.

> You need to cleanup global static structures as well and you will have
> no control over pointers pointing to dynamic allocated memory that got
> lost in a longjmp.

>>> and will not prevent QGIS from
>>> terminating or segfaulting eventually in case of a fatal error.
>>
>> Why?
>
> Because of the undefined state of global variables and structures and
> because of potential memory leaks that may sum up making QGIS
> unusable.

In theory maybe, in practice it will work and it DOES work with GRASS
6. I don't care about few bytes lost. G_fatal_error() is really rare
in QGIS provider/plugin, it should be rare.

Radim