[GRASS-dev] [GRASS GIS] #869: Compile libs with -fexception

GRASS GRASS developer
,
1

#869: Compile libs with -fexception
-----------------------+----------------------------------------------------
Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
     Type: defect | Status: new
Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Keywords: | Platform: Unspecified
      Cpu: All |
-----------------------+----------------------------------------------------
I know, I want probably too much. Would it be possible to compile GRASS
libraries (at least core libs gis, vect, ...) with -fexception by default?

The problem is, that for example QGIS, sets error routine which throws an
exception, everything works (even on Windows) but only if GRASS libs are
compiled with -fexception. If -fexception flag is not used, the exception
is thrown, but cannot be caught in QGIS and program is terminated.

QGIS ticket http://trac.osgeo.org/qgis/ticket/1878

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/869&gt;
GRASS GIS <http://grass.osgeo.org>

2

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
  Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
  Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Changes (by glynn):

  * status: new => closed
  * resolution: => worksforme

Comment:

Replying to [ticket:869 rblazek]:
> I know, I want probably too much.

You do. Although it's not just you (see also: the vdigit module).

> Would it be possible to compile GRASS libraries (at least core libs gis,
vect, ...) with -fexception by default?

The GRASS libraries exist for GRASS, not QGIS.

Right now, I'm actively trying to think of ways to make life harder for
anyone trying to use the GRASS libraries for anything except GRASS
modules.

There are basically two types of people in the world: those who understand
how much effort is saved by relying upon the OS' process mechanism for
memory management and error recovery, and those who want the GRASS
libraries to be usable in persistent applications.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/869#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

3

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
  Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
  Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Comment (by rblazek):

Well, I expected something like that, but I must say, that I did not
expect, that you want "to make life harder for anyone trying to use the
GRASS libraries". I always thought that you are just ignoring them.

I think that this ticket should be closed as wontfix, not worksforme.

Can you discover more about how you want to disable use of GRASS
libraries, it could save us wasting time.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/869#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

4

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
  Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
  Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Comment (by martinl):

Replying to [comment:2 rblazek]:
> Well, I expected something like that, but I must say, that I did not
expect, that you want "to make life harder for anyone trying to use the
GRASS libraries". I always thought that you are just ignoring them.
>
> I think that this ticket should be closed as wontfix, not worksforme.
>
> Can you discover more about how you want to disable use of GRASS
libraries, it could save us wasting time.

I think that ignoring people who are using GRASS libraries can be not good
for GRASS project itself. This is my personal opinion.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/869#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

5

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
  Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
  Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Comment (by neteler):

Replying to [comment:1 glynn]:
..
> Right now, I'm actively trying to think of ways to make life harder for
anyone trying to use the GRASS libraries for anything except GRASS
modules.

I think I have to comment here:

This statement sounds a bit radical to me and don't think that it reflects
the idea of collaboration across OSGeo projects.

Markus

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/869#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

6

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
  Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
  Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Old description:

I know, I want probably too much. Would it be possible to compile GRASS
libraries (at least core libs gis, vect, ...) with -fexception by
default?

The problem is, that for example QGIS, sets error routine which throws an
exception, everything works (even on Windows) but only if GRASS libs are
compiled with -fexception. If -fexception flag is not used, the exception
is thrown, but cannot be caught in QGIS and program is terminated.

QGIS ticket http://trac.osgeo.org/qgis/ticket/1878

New description:

I know, I want probably too much. Would it be possible to compile GRASS
libraries (at least core libs gis, vect, ...) with -fexception by default?

The problem is, that for example QGIS, sets error routine which throws an
exception, everything works (even on Windows) but only if GRASS libs are
compiled with -fexception. If -fexception flag is not used, the exception
is thrown, but cannot be caught in QGIS and program is terminated.

QGIS ticket http://trac.osgeo.org/qgis/ticket/1878

Comment (by neteler):

Replying to [ticket:869 rblazek]:
> I know, I want probably too much. Would it be possible to compile GRASS
libraries (at least core libs gis, vect, ...) with -fexception by default?

I have recompiled with -fexceptions (note the s)

{{{
# using something like this:
CFLAGS="-fexceptions" ./configure ...
}}}

and did not encounter any problems in GRASS 6.4.

Radim, where do you want to see -fexceptions be used?

Markus

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/869#comment:5&gt;
GRASS GIS <http://grass.osgeo.org>

7

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
  Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
  Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Comment (by glynn):

Replying to [comment:2 rblazek]:

> Well, I expected something like that, but I must say, that I did not
expect, that you want "to make life harder for anyone trying to use the
GRASS libraries". I always thought that you are just ignoring them.

As it appears not have been obvious, the comment wasn't entirely serious.
Although it's not without some basis.

> I think that this ticket should be closed as wontfix, not worksforme.

I spent some time thinking about this, and concluded that "worksforme" is
correct. The libraries work for their intended purpose, i.e. GRASS
modules. "wontfix" implies that there's something to fix.

> Can you discover more about how you want to disable use of GRASS
libraries, it could save us wasting time.

It's not that I'm actually planning to disable anything, just that making
any changes which make their intended uses harder for the benefit of
unintended use would occur over my dead body (well, my departure). Ditto
for foregoing changes which would make intended use easier (e.g. recent
changes to 7.0 mean that functions such as Rast_open_* and
Rast_{get,put}_row now generate a fatal error, so callers don't have to
deal with this themselves).

In that regard, -fexceptions doesn't benefit GRASS itself in any way,
would require various configure checks to ensure that the compiler
actually supports that flag, increases memory usage (according to the gcc
docs), and may not actually help you at all (because unwinding the stack
isn't going to magically revert any incomplete modifications, so there's
no guarantee that the next call to a library function won't just segfault;
and that's not a bug; once G_fatal_error() has been called, all bets are
off).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/869#comment:6&gt;
GRASS GIS <http://grass.osgeo.org>

8

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
  Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
  Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Comment (by rblazek):

Replying to [comment:5 neteler]:
> Radim, where do you want to see -fexceptions be used?

In Lib.make? As Glynn pointed out, a test must be done if it is supported
by compiler.

BUT! You don't want to see Glynn's "dead body", I believe!

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/869#comment:7&gt;
GRASS GIS <http://grass.osgeo.org>

9

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
  Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
  Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Comment (by hamish):

fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:

{{{
This would be required for any C library linked by Qgis. This is out of
discussion.
Qgis has to manage correctly C libraries by providing wrappers to raise
execeptions
when C calls fail, else people will start asking that libc too supports
exceptions, soon or later...
}}}

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/869#comment:8&gt;
GRASS GIS <http://grass.osgeo.org>

10

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
  Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
  Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Comment (by rblazek):

Replying to [comment:8 hamish]:
> fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:
>
{{{
  This would be required for any C library linked by Qgis. This is out of
discussion.
  Qgis has to manage correctly C libraries by providing wrappers to raise
execeptions
  when C calls fail, else people will start asking that libc too supports
  exceptions, soon or later...
}}}

Probably he does not know, that GRASS libraries can call exit(). No
wrapper can help in that situation AFAIK.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/869#comment:9&gt;
GRASS GIS <http://grass.osgeo.org>

11

I use in vtk.grass-bridge (C++ -VTK GRASS wrapper) a different approach.
http://code.google.com/p/vtk-grass-bridge/

Replacing the G_fatal_error() function and using the setjmp/longjmp
construct allows you to catch all errors from grass, inclusively stack
restoration. Glynn made this suggestion. :slight_smile:

This function replace G_fatal_error(), to set with
G_set_error_routine(vgb_error_handler);:

int vgb_error_handler(const char *msg, int fatal)
{
    if (fatal == 0)
    {
        fprintf(stderr, "%s\n", msg);
        return 1;
    }
    else
    {
        fprintf(stderr, "\n############## Exceptiont called ###########\n");
        vgb_error_message = msg;
        longjmp(vgb_stack_buffer, 1);
    }
    return 1;
}

This is an example how to handle fatal errors (old example, still
check for return value):
    if (!setjmp(vgb_stack_buffer))
    {
        if (Rast_get_row(this->Map, this->RasterBuff, idx, this->MapType) < 0)
        {
            error = 1;
        }
    }
    else
    {
        this->InsertNextError(vgb_error_message);
        return NULL;
    }

Code examples from:
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSDefines.h
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSInit.cxx
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Raster/vtkGRASSRasterMapBase.cxx

Soeren

2010/1/14 GRASS GIS <trac@osgeo.org>:

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Comment (by rblazek):

Replying to [comment:8 hamish]:
> fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:
>
{{{
This would be required for any C library linked by Qgis. This is out of
discussion.
Qgis has to manage correctly C libraries by providing wrappers to raise
execeptions
when C calls fail, else people will start asking that libc too supports
exceptions, soon or later...
}}}

Probably he does not know, that GRASS libraries can call exit(). No
wrapper can help in that situation AFAIK.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/869#comment:9&gt;
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

12

Thanks for the suggestion. The title of
http://trac.osgeo.org/qgis/ticket/1878 is however "remove
setjmp/longjmp in grass plugin&provider and use exceptions instead" so
the intention was to remove setjmp/longjmp.
I don't know exactly if there were problems with setjmp/longjmp or it
was just attempt to improve the code. Using exceptions is certainly
better.

Radim

On Thu, Jan 14, 2010 at 4:59 PM, Soeren Gebbert
<soerengebbert@googlemail.com> wrote:

I use in vtk.grass-bridge (C++ -VTK GRASS wrapper) a different approach.
http://code.google.com/p/vtk-grass-bridge/

Replacing the G_fatal_error() function and using the setjmp/longjmp
construct allows you to catch all errors from grass, inclusively stack
restoration. Glynn made this suggestion. :slight_smile:

This function replace G_fatal_error(), to set with
G_set_error_routine(vgb_error_handler);:

int vgb_error_handler(const char *msg, int fatal)
{
if (fatal == 0)
{
fprintf(stderr, "%s\n", msg);
return 1;
}
else
{
fprintf(stderr, "\n############## Exceptiont called ###########\n");
vgb_error_message = msg;
longjmp(vgb_stack_buffer, 1);
}
return 1;
}

This is an example how to handle fatal errors (old example, still
check for return value):
if (!setjmp(vgb_stack_buffer))
{
if (Rast_get_row(this->Map, this->RasterBuff, idx, this->MapType) < 0)
{
error = 1;
}
}
else
{
this->InsertNextError(vgb_error_message);
return NULL;
}

Code examples from:
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSDefines.h
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSInit.cxx
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Raster/vtkGRASSRasterMapBase.cxx

Soeren

2010/1/14 GRASS GIS <trac@osgeo.org>:

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Comment (by rblazek):

Replying to [comment:8 hamish]:
> fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:
>
{{{
This would be required for any C library linked by Qgis. This is out of
discussion.
Qgis has to manage correctly C libraries by providing wrappers to raise
execeptions
when C calls fail, else people will start asking that libc too supports
exceptions, soon or later...
}}}

Probably he does not know, that GRASS libraries can call exit(). No
wrapper can help in that situation AFAIK.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/869#comment:9&gt;
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

13

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
  Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
  Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Comment (by frankie):

Replying to [comment:9 rblazek]:
> Replying to [comment:8 hamish]:
> > fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:
> >
> {{{
> This would be required for any C library linked by Qgis. This is out of
discussion.
> Qgis has to manage correctly C libraries by providing wrappers to raise
execeptions
> when C calls fail, else people will start asking that libc too supports
> exceptions, soon or later...
> }}}
>
> Probably he does not know, that GRASS libraries can call exit(). No
wrapper can help in that situation AFAIK.

Right, libc and system calls :wink: Out of joking, those cases requires
refining the library design, not dirty work arounds with limited results.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/869#comment:10&gt;
GRASS GIS <http://grass.osgeo.org>

14

Radim Blazek wrote:

Thanks for the suggestion. The title of
http://trac.osgeo.org/qgis/ticket/1878 is however "remove
setjmp/longjmp in grass plugin&provider and use exceptions instead" so
the intention was to remove setjmp/longjmp.
I don't know exactly if there were problems with setjmp/longjmp or it
was just attempt to improve the code. Using exceptions is certainly
better.

Whichever approach is used, any code calling G_fatal_error() is
entitled to assume that it won't be called again, so it doesn't need
to perform clean-up.

If you leave the error handler via longjmp() or an exception, then
re-enter the GRASS libraries, all bets are off.

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

15

Hi,

2010/1/14 Glynn Clements <glynn@gclements.plus.com>:

[...]

Whichever approach is used, any code calling G_fatal_error() is
entitled to assume that it won't be called again, so it doesn't need
to perform clean-up.

OFT, some clean-up (at module level) would be reasonable, e.g. to
delete output raster/vector map if module fails.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

16

Martin Landa wrote:

> Whichever approach is used, any code calling G_fatal_error() is
> entitled to assume that it won't be called again, so it doesn't need
> to perform clean-up.

OFT, some clean-up (at module level) would be reasonable, e.g. to
delete output raster/vector map if module fails.

I was referring specifically to clean-up of in-memory data structures.

Output raster maps are written to a temporary file, which is renamed
into place when the map is closed. If an error occurs, it will result
in a temporary file being left behind, rather than affecting any
existing output map.

This could probably be handled better (e.g. support files are normally
overwritten in place), but this would be better addressed as part of a
more wide-ranging re-organisation of the database layout. There was
some discussion here a while back, although nothing concrete came of
it. It isn't easy to fix without substantially affecting the API.

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

17

#869: Compile libs with -fexception
--------------------------+-------------------------------------------------
  Reporter: rblazek | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: unspecified
Resolution: worksforme | Keywords:
  Platform: Unspecified | Cpu: All
--------------------------+-------------------------------------------------
Comment (by lutra):

Replying to [comment:1 glynn]:

> Right now, I'm actively trying to think of ways to make life harder for
anyone trying to use the GRASS libraries for anything except GRASS
modules.

for what it's worth... -1

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/869#comment:11&gt;
GRASS GIS <http://grass.osgeo.org>