[GRASS-dev] grass7 problems with MASK

GRASS GRASS developer
1

Because of r40217, Rast_close() and Rast_unopen() can no longer be called unconditionally. That gives me errors when a MASK is present:
ERROR: Invalid descriptor: 0

The following patch to lib/raster works for me but I'm not sure if this is the right way

Index: init.c

--- init.c (revision 40418)
+++ init.c (working copy)
@@ -83,6 +83,7 @@
      /* Set masking flag unknown */
     R__.auto_mask = -1;
+ R__.mask_fd = -1;
      R__.nbytes = sizeof(CELL);
     R__.compression_type = getenv("GRASS_INT_ZLIB") ? 2 : 1;
Index: auto_mask.c

--- auto_mask.c (revision 40418)
+++ auto_mask.c (working copy)
@@ -61,7 +61,9 @@
     return 0;
     }
- Rast_unopen(R__.mask_fd);
+ if (R__.mask_fd >= 0)
+ Rast_unopen(R__.mask_fd);
+ R__.mask_fd = Rast__open_old("MASK", G_mapset());
     if (R__.mask_fd < 0) {
     R__.auto_mask = 0;

Alternatively, just return if a raster map can't be unopened/closed?

Markus M

2

Hi,
i have had the same problem and implemented an identical solution.
But the problem was hard to figure out, because G_fatal_error() is now called
if opening or closing of maps fails.
The problem appeared when i started r.sim.water after creating a mask.
So i searched the error first in r.sim.water, because i changed the
memory allocation
recently and enabled the compilation of this module.

After a while i implemented an artificial segfault in G_fatal_error()
to enable debugging with gdb and valgrind and found the problem.

Therefor i would like to suggest to establish an environmental
variable to enable
G_fatal_error() to segfault for better error debugging. I was thinking
of a variable
in gisrc, but this will result in an infinite G_fatal_error()
call-loop, because G_fatal_error() is called in case the environmental
variable is not present in gisrc.

What would be the best way to implement such an behavior of G_fatal_error()?
Any suggestions are welcome.

Best
Soeren

2010/1/13 Markus Metz <markus.metz.giswork@googlemail.com>:

Because of r40217, Rast_close() and Rast_unopen() can no longer be called
unconditionally. That gives me errors when a MASK is present:
ERROR: Invalid descriptor: 0

The following patch to lib/raster works for me but I'm not sure if this is
the right way

Index: init.c

--- init.c (revision 40418)
+++ init.c (working copy)
@@ -83,6 +83,7 @@

/* Set masking flag unknown */
R__.auto_mask = -1;
+ R__.mask_fd = -1;

R__.nbytes = sizeof(CELL);
R__.compression_type = getenv("GRASS_INT_ZLIB") ? 2 : 1;
Index: auto_mask.c

--- auto_mask.c (revision 40418)
+++ auto_mask.c (working copy)
@@ -61,7 +61,9 @@
return 0;
}

- Rast_unopen(R__.mask_fd);
+ if (R__.mask_fd >= 0)
+ Rast_unopen(R__.mask_fd);
+ R__.mask_fd = Rast__open_old("MASK", G_mapset());
if (R__.mask_fd < 0) {
R__.auto_mask = 0;

Alternatively, just return if a raster map can't be unopened/closed?

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

3

Markus Metz wrote:

Because of r40217, Rast_close() and Rast_unopen() can no longer be
called unconditionally. That gives me errors when a MASK is present:
ERROR: Invalid descriptor: 0

The following patch to lib/raster works for me but I'm not sure if this
is the right way

It looks correct to me.

Committed as r40419.

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

4

Soeren Gebbert wrote:

Therefor i would like to suggest to establish an environmental
variable to enable G_fatal_error() to segfault for better error
debugging. I was thinking of a variable in gisrc, but this will
result in an infinite G_fatal_error() call-loop, because
G_fatal_error() is called in case the environmental variable is not
present in gisrc.

What would be the best way to implement such an behavior of G_fatal_error()?
Any suggestions are welcome.

Use an environment variable rather than a GRASS ($GISRC) variable,
e.g.

  if (getenv("GRASS_ABORT_ON_ERROR"))
      abort();

An abort is preferable to trying to create a segfault, as abort() is
specified by the ANSI/ISO C standard, while generating a segfault
relies upon undefined behaviour (which means that there is no robust
way to force a segfault to occur; the most obvious approach is prone
to being optimised-out).

The default behaviour for SIGABRT is to terminate and dump core, the
same as for SIGSEGV, so I'm not sure that there's any benefit to a
segfault. If you really need SIGSEGV, raise(SIGSEGV) might be better
(but does this signal exist on Windows?).

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

5

Hello,

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

Soeren Gebbert wrote:

Therefor i would like to suggest to establish an environmental
variable to enable G_fatal_error() to segfault for better error
debugging. I was thinking of a variable in gisrc, but this will
result in an infinite G_fatal_error() call-loop, because
G_fatal_error() is called in case the environmental variable is not
present in gisrc.

What would be the best way to implement such an behavior of G_fatal_error()?
Any suggestions are welcome.

Use an environment variable rather than a GRASS ($GISRC) variable,
e.g.

   if \(getenv\(&quot;GRASS\_ABORT\_ON\_ERROR&quot;\)\)
       abort\(\);

An abort is preferable to trying to create a segfault, as abort() is
specified by the ANSI/ISO C standard, while generating a segfault
relies upon undefined behaviour (which means that there is no robust
way to force a segfault to occur; the most obvious approach is prone
to being optimised-out).

The default behaviour for SIGABRT is to terminate and dump core, the
same as for SIGSEGV, so I'm not sure that there's any benefit to a
segfault. If you really need SIGSEGV, raise(SIGSEGV) might be better
(but does this signal exist on Windows?).

Regarding the Microsoft Run-Time-Library documentation it should exist:
http://msdn.microsoft.com/de-de/library/5s651ehs(VS.80).aspx

I will add these lines to lib/gis/error.c in grass7.

    if (getenv("GRASS_SIGSEGV_ON_ERROR"))
        raise(SIGSEGV);

Where is the best place to document the new grass environment variable?

Thanks
Soeren

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

6

On Mon, Jan 18, 2010 at 3:50 PM, Soeren Gebbert
<soerengebbert@googlemail.com> wrote:
...

Where is the best place to document the new grass environment variable?

It should go here (IMHO):

lib/init/variables.html

Markus