[GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing

GRASS GRASS developer
1

On Wed, May 22, 2002 at 05:57:17PM +0200, Glynn Clements via RT wrote:

Request Tracker wrote:

> Subject: [rsv].proj are crashing
>
> grass binary for platform: Compiled from Sources
>
> A critical bug report:
>
> v.proj in=austria loca=europa mapset=europa
> Segmentation fault (core dumped)
>
> Also r.proj (and eventually s.proj, untested) are affected.
>
> I have spent some time in src/libes/gis/env.c where the crash occurs
> in line 195 of get_env() function. The reason is unclear to me why
> strcmp() crashes sometimes (maybe someone else understands the
> problem).

If strcmp() crashes, one of its arguments is invalid, in the sense
that either:

a) it points to an invalid address (e.g. NULL), or
b) it points to a valid address, but scanning the string reaches an
invalid address before it reads a terminating NUL byte.

So, something is passing bad values to strcmp(). In this instance,
either the "environment" is bad, or the caller is passing a bad "name"
argument to G_getenv() or similar.

Here is the output of g.gisenv:

g.gisenv
LOCATION_NAME=sjtsk
MAPSET=neteler
DIGITIZER=none
GISDBASE=/ssi0/ssi/blazek/pub
MONITOR=x0
GRASS_GUI=text

which looks o.k. Also during the debugging the values seemed to
be always set.

Is there anyone else who could try the latest [rvs].proj from
CVS (pre4 or HEAD)?

Thanks,

Markus

2

On Wed, May 22, 2002 at 06:06:53PM +0200, Markus Neteler wrote:

On Wed, May 22, 2002 at 05:57:17PM +0200, Glynn Clements via RT wrote:
>
> Request Tracker wrote:
>
> > Subject: [rsv].proj are crashing
> >
> > grass binary for platform: Compiled from Sources
> >
> > A critical bug report:
> >
> > v.proj in=austria loca=europa mapset=europa
> > Segmentation fault (core dumped)
> >
> > Also r.proj (and eventually s.proj, untested) are affected.
> >
> > I have spent some time in src/libes/gis/env.c where the crash occurs
> > in line 195 of get_env() function. The reason is unclear to me why
> > strcmp() crashes sometimes (maybe someone else understands the
> > problem).
>
> If strcmp() crashes, one of its arguments is invalid, in the sense
> that either:
>
> a) it points to an invalid address (e.g. NULL), or
> b) it points to a valid address, but scanning the string reaches an
> invalid address before it reads a terminating NUL byte.
>
> So, something is passing bad values to strcmp(). In this instance,
> either the "environment" is bad, or the caller is passing a bad "name"
> argument to G_getenv() or similar.

Here is the output of g.gisenv:

g.gisenv
LOCATION_NAME=sjtsk
MAPSET=neteler
DIGITIZER=none
GISDBASE=/ssi0/ssi/blazek/pub
MONITOR=x0
GRASS_GUI=text

which looks o.k. Also during the debugging the values seemed to
be always set.

Is there anyone else who could try the latest [rvs].proj from
CVS (pre4 or HEAD)?

A followup: I had added some debug output into the function in
env.c:

r.proj in=dtm1km loca=europa mapset=europa dbase=/ssi0/ssi/neteler/grassdata
count: 6 n: 0 env[n].name: LOCATION_NAME name: LOCATION_NAME
n: 0 env[n].value sjtsk

count: 6 n: 0 env[n].name: LOCATION_NAME name: GISDBASE
count: 6 n: 1 env[n].name: MAPSET name: GISDBASE
count: 6 n: 2 env[n].name: DIGITIZER name: GISDBASE
count: 6 n: 3 env[n].name: GISDBASE name: GISDBASE
n: 3 env[n].value /ssi0/ssi/blazek/pub

count: 6 n: 0 env[n].name: LOCATION_NAME name: MAPSET
count: 6 n: 1 env[n].name: MAPSET name: MAPSET
n: 1 env[n].value neteler

count: 6 n: 0 env[n].name: LOCATION_NAME name: LOCATION_NAME
n: 0 env[n].value sjtsk

count: 6 n: 0 env[n].name: LOCATION_NAME name: GISDBASE
count: 6 n: 1 env[n].name: MAPSET name: GISDBASE
count: 6 n: 2 env[n].name: DIGITIZER name: GISDBASE
count: 6 n: 3 env[n].name: GISDBASE name: GISDBASE
n: 3 env[n].value /ssi0/ssi/blazek/pub

count: 6 n: 0 env[n].name: LOCATION_NAME name: LOCATION_NAME
n: 0 env[n].value sjtsk

count: 6 n: 0 env[n].name: LOCATION_NAME name: GISDBASE
count: 6 n: 1 env[n].name: MAPSET name: GISDBASE
count: 6 n: 2 env[n].name: DIGITIZER name: GISDBASE
count: 6 n: 3 env[n].name: GISDBASE name: GISDBASE
n: 3 env[n].value /ssi0/ssi/blazek/pub

count: 6 n: 0 env[n].name: LOCATION_NAME name: LOCATION_NAME
n: 0 env[n].value sjtsk

count: 6 n: 0 env[n].name: LOCATION_NAME name: MAPSET
count: 6 n: 1 env[n].name: MAPSET name: MAPSET
n: 1 env[n].value neteler

count: 6 n: 0 env[n].name: LOCATION_NAME name: LOCATION_NAME
n: 0 env[n].value sjtsk

count: 6 n: 0 env[n].name: LOCATION_NAME name: GISDBASE
count: 6 n: 1 env[n].name: MAPSET name: GISDBASE
count: 6 n: 2 env[n].name: DIGITIZER name: GISDBASE
count: 6 n: 3 env[n].name: GISDBASE name: GISDBASE
n: 3 env[n].value /ssi0/ssi/blazek/pub

count: 6 n: 0 env[n].name: LOCATION_NAME name: LOCATION_NAME
n: 0 env[n].value sjtsk

count: 6 n: 0 env[n].name: LOCATION_NAME name: GISDBASE
count: 6 n: 1 env[n].name: MAPSET name: GISDBASE
count: 6 n: 2 env[n].name: DIGITIZER name: GISDBASE
count: 6 n: 3 env[n].name: GISDBASE name: GISDBASE
n: 3 env[n].value /ssi0/ssi/blazek/pub

count: 6 n: 0 env[n].name: LOCATION_NAME name: LOCATION_NAME
n: 0 env[n].value sjtsk

count: 6 n: 0 env[n].name: LOCATION_NAME name: GISDBASE
count: 6 n: 1 env[n].name: MAPSET name: GISDBASE
count: 6 n: 2 env[n].name: DIGITIZER name: GISDBASE
count: 6 n: 3 env[n].name: GISDBASE name: GISDBASE
n: 3 env[n].value /ssi0/ssi/blazek/pub

count: 6 n: 0 env[n].name: LOCATION_NAME name: LOCATION_NAME
n: 0 env[n].value sjtsk

count: 6 n: 0 env[n].name: LOCATION_NAME name: GISDBASE
count: 6 n: 1 env[n].name: MAPSET name: GISDBASE
count: 6 n: 2 env[n].name: DIGITIZER name: GISDBASE
count: 6 n: 3 env[n].name: GISDBASE name: GISDBASE
n: 3 env[n].value /ssi0/ssi/blazek/pub

count: 6 n: 0 env[n].name: LOCATION_NAME name: LOCATION_NAME
n: 0 env[n].value sjtsk

count: 6 n: 0 env[n].name: LOCATION_NAME name: GISDBASE
count: 6 n: 1 env[n].name: MAPSET name: GISDBASE
count: 6 n: 2 env[n].name: DIGITIZER name: GISDBASE
count: 6 n: 3 env[n].name: GISDBASE name: GISDBASE
n: 3 env[n].value /ssi0/ssi/blazek/pub

Segmentation fault (core dumped)

In general the function seems to work well (it is used often,
only it suddenly crashes).

Markus

3

Markus Neteler wrote:

> > If strcmp() crashes, one of its arguments is invalid, in the sense
> > that either:
> >
> > a) it points to an invalid address (e.g. NULL), or
> > b) it points to a valid address, but scanning the string reaches an
> > invalid address before it reads a terminating NUL byte.
> >
> > So, something is passing bad values to strcmp(). In this instance,
> > either the "environment" is bad, or the caller is passing a bad "name"
> > argument to G_getenv() or similar.
>
> Here is the output of g.gisenv:
>
> g.gisenv
> LOCATION_NAME=sjtsk
> MAPSET=neteler
> DIGITIZER=none
> GISDBASE=/ssi0/ssi/blazek/pub
> MONITOR=x0
> GRASS_GUI=text
>
> which looks o.k. Also during the debugging the values seemed to
> be always set.
>
> Is there anyone else who could try the latest [rvs].proj from
> CVS (pre4 or HEAD)?

A followup: I had added some debug output into the function in
env.c:

[snip]

Your debug output doesn't make much sense.

In general the function seems to work well (it is used often,
only it suddenly crashes).

Basically, there are two likely possibilities. Either something is
corrupting the environment array, or something is passing a bad
argument to G_getenv() or similar.

The only reliable way to find out exactly what is happening is to
examine the program state at the point that the segfault occurs;
primarily, the arguments which are passed to strcmp().

--
Glynn Clements <glynn.clements@virgin.net>

4

On Wed, May 22, 2002 at 11:41:40PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> > > If strcmp() crashes, one of its arguments is invalid, in the sense
> > > that either:
> > >
> > > a) it points to an invalid address (e.g. NULL), or
> > > b) it points to a valid address, but scanning the string reaches an
> > > invalid address before it reads a terminating NUL byte.
> > >
> > > So, something is passing bad values to strcmp(). In this instance,
> > > either the "environment" is bad, or the caller is passing a bad "name"
> > > argument to G_getenv() or similar.
> >
> > Here is the output of g.gisenv:
> >
> > g.gisenv
> > LOCATION_NAME=sjtsk
> > MAPSET=neteler
> > DIGITIZER=none
> > GISDBASE=/ssi0/ssi/blazek/pub
> > MONITOR=x0
> > GRASS_GUI=text
> >
> > which looks o.k. Also during the debugging the values seemed to
> > be always set.
> >
> > Is there anyone else who could try the latest [rvs].proj from
> > CVS (pre4 or HEAD)?
>
> A followup: I had added some debug output into the function in
> env.c:

[snip]

Your debug output doesn't make much sense.

Possible.
So I have continued.

> In general the function seems to work well (it is used often,
> only it suddenly crashes).

Basically, there are two likely possibilities. Either something is
corrupting the environment array, or something is passing a bad
argument to G_getenv() or similar.

The only reliable way to find out exactly what is happening is to
examine the program state at the point that the segfault occurs;
primarily, the arguments which are passed to strcmp().

Following fix cures the problem for env.c:
cvs diff -u env.c
RCS file: /grassrepository/grass/src/libes/gis/env.c,v
retrieving revision 1.5
diff -u -r1.5 env.c
--- env.c 12 May 2002 12:04:45 -0000 1.5
+++ env.c 23 May 2002 08:25:33 -0000
@@ -177,13 +177,12 @@
     int n;

     for (n = 0; n < count; n++)
- if (env[n].name && (strcmp(env[n].name, name)==0))
+ if (env[n].name && (strlen(name)!=0) && (strcmp(env[n].name, name)==0))
        {
            free (env[n].name);
            env[n].name = 0;
            return 1;
        }
-
     return 0;
}

Objections to submit this fix?

But...
Then the next bug occurs due to the new NAD datum support:
In r.proj/main.c line 279 is the function G_database_datum_name() used:
   strncpy(in_datum,G_database_datum_name(),sizeof(in_datum));
For my existing locations it returns NULL which causes a crash
of strncpy(). The function G_database_datum_name() is in
src/libes/gis/proj3.c

How to solve that one (hi Roger)? Therefore [vs].proj are also affected.

Markus

5

On Thu, May 23, 2002 at 10:26:14AM +0200, Markus Neteler wrote:
[...]

But...
Then the next bug occurs due to the new NAD datum support:
In r.proj/main.c line 279 is the function G_database_datum_name() used:
   strncpy(in_datum,G_database_datum_name(),sizeof(in_datum));
For my existing locations it returns NULL which causes a crash
of strncpy(). The function G_database_datum_name() is in
src/libes/gis/proj3.c

How to solve that one (hi Roger)? Therefore [vs].proj are also affected.

A followup:
After using 'g.setproj' in the source location (for r.proj) to define
the map datum, r.proj works fine.

Means: we need a change in case no map datum is present in the
PROJ_INFO file (which will be the case for many locations out there,
especially since the definition of a map datum is not forced).

6

On Thu, May 23, 2002 at 10:32:20AM +0200, Markus Neteler wrote:

On Thu, May 23, 2002 at 10:26:14AM +0200, Markus Neteler wrote:
[...]
> But...
> Then the next bug occurs due to the new NAD datum support:
> In r.proj/main.c line 279 is the function G_database_datum_name() used:
> strncpy(in_datum,G_database_datum_name(),sizeof(in_datum));
> For my existing locations it returns NULL which causes a crash
> of strncpy(). The function G_database_datum_name() is in
> src/libes/gis/proj3.c
>
> How to solve that one (hi Roger)? Therefore [vs].proj are also affected.

A followup:
After using 'g.setproj' in the source location (for r.proj) to define
the map datum, r.proj works fine.

Means: we need a change in case no map datum is present in the
PROJ_INFO file (which will be the case for many locations out there,
especially since the definition of a map datum is not forced).

Next followup: After applying the datum to the source location I
get the next trap (sigh).

r.proj in=dtm.10meters loc=pat map=dtm.10meters dbase=/ssi0/ssi/neteler/grassdata
cannot initialize pj
cause: unknown elliptical parameter name
ERROR: Can't get projection key values of output map

Tracking down the problem, I have found that in pj_get_kv() in
src/libes/proj/get_proj.c
the "ellips=name" is not put into the structure "in_proj_keys".
Looking into the Changelog, I found:
  2001-10-23 03:33 frankw
        * get_proj.c: dont pass through ellps= if we have defining
        parameters

The former version of PROJ4 in GRASS was able to deal with this case,
I recall that the change done by Frank was required to work around
problems with r.in.gdal.

However, after update of PROJ4 (or another reason), the "ellps"
seems to be required again.

Is a modification needed around line 71 in get_proj.c?

Markus

7

On Thu, 23 May 2002, Markus Neteler wrote:

the "ellips=name" is not put into the structure "in_proj_keys".
Looking into the Changelog, I found:
  2001-10-23 03:33 frankw
        * get_proj.c: dont pass through ellps= if we have defining
        parameters

The former version of PROJ4 in GRASS was able to deal with this case,
I recall that the change done by Frank was required to work around
problems with r.in.gdal.

The way grass used to co-operate with proj was that grass _never_ passed
the ellipsoid name to proj, but always uses the a and e2 values instead. a
and e2 were taken from the PROJ_INFO file, or (in the case of m.proj)
looked up from grass' ellipsoid table. The ellipsoid name in PROJ_INFO was
only there for display, but is never really used, unless someone added or
changed a module to pass the name to proj.

If proj itself would have have changed so +ellps= is a required argument,
no projection routine in grass would work. I guess this is unlikely.

Morten Hulden

8

On Thursday 23 May 2002 02:26, Markus Neteler wrote:

Following fix cures the problem for env.c:
cvs diff -u env.c
RCS file: /grassrepository/grass/src/libes/gis/env.c,v
retrieving revision 1.5
diff -u -r1.5 env.c
--- env.c 12 May 2002 12:04:45 -0000 1.5
+++ env.c 23 May 2002 08:25:33 -0000
@@ -177,13 +177,12 @@
     int n;

     for (n = 0; n < count; n++)
- if (env[n].name && (strcmp(env[n].name, name)==0))
+ if (env[n].name && (strlen(name)!=0) && (strcmp(env[n].name,
name)==0)) {
            free (env[n].name);
            env[n].name = 0;
            return 1;
        }
-
     return 0;
}

Objections to submit this fix?

Markus, if an empty string caused the problem, then maybe a better fix would
be to change set_env so that an empty string never stored. An empty string
could be treated like a NULL.

At line 125 in env.c the statement

if(!value)

could be changed to

if(!value || !strlen(value))

That way an empty string is treated the same way as sending a NULL string and
causes GRASS to unset the environment variable.

But...
Then the next bug occurs due to the new NAD datum support:
In r.proj/main.c line 279 is the function G_database_datum_name() used:
   strncpy(in_datum,G_database_datum_name(),sizeof(in_datum));
For my existing locations it returns NULL which causes a crash
of strncpy(). The function G_database_datum_name() is in
src/libes/gis/proj3.c

How to solve that one (hi Roger)? Therefore [vs].proj are also affected.

Uhh. I guess I did know about that problem. A check is easily added. My
preference would be also to change G_database_datum_name() so that it does
not return NULL (maybe returning a pointer to "unknown" instead) and/or
ensuring that the datum is never blank.

Roger Miller

9

On Thu, May 23, 2002 at 12:52:12PM +0200, Morten Hulden wrote:

On Thu, 23 May 2002, Markus Neteler wrote:

> the "ellips=name" is not put into the structure "in_proj_keys".
> Looking into the Changelog, I found:
> 2001-10-23 03:33 frankw
> * get_proj.c: dont pass through ellps= if we have defining
> parameters
>
> The former version of PROJ4 in GRASS was able to deal with this case,
> I recall that the change done by Frank was required to work around
> problems with r.in.gdal.

The way grass used to co-operate with proj was that grass _never_ passed
the ellipsoid name to proj, but always uses the a and e2 values instead. a
and e2 were taken from the PROJ_INFO file, or (in the case of m.proj)
looked up from grass' ellipsoid table. The ellipsoid name in PROJ_INFO was
only there for display, but is never really used, unless someone added or
changed a module to pass the name to proj.

If proj itself would have have changed so +ellps= is a required argument,
no projection routine in grass would work. I guess this is unlikely.

Thanks for the hint. In that case the problem has to be located
here:
pj_init() called from get_init.c
from
src/libes/proj/pj_init.c

This file was changed in the PROJ4.4.5 (try:
cvs diff -u -r1.1 pj_init.c
inside CVS). There is a line
  if( strncmp(word,"ellps=",6) != 0
inside which wasn't present in the former PROJ4 (ok, I do not understand
the code inside src/libes/proj/pj_init.c right now).

Still clueless,

Markus

PS: Since my locations are unchanged, the problem must be in GRASS.

10

On Thu, May 23, 2002 at 12:52:12PM +0200, Morten Hulden wrote:

On Thu, 23 May 2002, Markus Neteler wrote:

> the "ellips=name" is not put into the structure "in_proj_keys".
> Looking into the Changelog, I found:
> 2001-10-23 03:33 frankw
> * get_proj.c: dont pass through ellps= if we have defining
> parameters
>
> The former version of PROJ4 in GRASS was able to deal with this case,
> I recall that the change done by Frank was required to work around
> problems with r.in.gdal.

The way grass used to co-operate with proj was that grass _never_ passed
the ellipsoid name to proj, but always uses the a and e2 values instead. a
and e2 were taken from the PROJ_INFO file, or (in the case of m.proj)
looked up from grass' ellipsoid table. The ellipsoid name in PROJ_INFO was
only there for display, but is never really used, unless someone added or
changed a module to pass the name to proj.

If proj itself would have have changed so +ellps= is a required argument,
no projection routine in grass would work. I guess this is unlikely.

Morten Hulden

So: one problem is solved (above with the ellps).
[for env.c and the new datum functions see Roger's new mail).

The reason why I had above problem was (of course) an interference
of a new feature. Jaro Hofierka and me currently try to add the
Krovak projection to GRASS (Czech republic). This requires the
"hermannskogel" datum which is not present in PROJ4. No surprise
that it wasn't working. However, the PROJ4 error messages are
not really helpful.

diff pj_datums.c.old pj_datums.c
77a78

"hermannskogel", "towgs84=653.0,-212.0,449.0", "bessel", "Hermannskogel",

Summary of this long thread:
- Open problems:
  - bugfix needed in src/libes/gis/env.c
  - bugfix needed for G_database_datum_name() and G_database_ellipse_name()
    in src/libes/gis/proj3.c in case datum is absent in PROJ_INFO

- solved issue (we are verifying now the results):
  - implementation of Krovak and Krovakyx (with reverted coordinate system
    as usually used for Czech/Slovak(?) GIS data done
    If desired, I can upload to CVS/Head. It is a new feature
    (no flame war please).

   Proof (in a Krovakyx LOCATION):
   r.proj in=dgm1km loca=europa mapset=europa dbase=/ssi0/ssi/neteler/grassdata
Input:
Cols: 4800 (4800)
Rows: 6000 (6000)
North: 90.000000 (90.000000)
South: 40.000000 (40.000000)
West: -20.000000 (-20.000000)
East: 20.000000 (20.000000)
ew-res: 0.008333
ns-res 0.008333

Output:
Cols: 2000 (2000)
Rows: 3000 (3000)
North: -400000.000000 (-400000.000000)
South: -700000.000000 (-700000.000000)
West: -1000000.000000 (-1000000.000000)
East: -800000.000000 (-800000.000000)
ew-res: 100.000000
ns-res 100.000000
Allocating memory and reading input map... d.erase4%
100%
Projecting... d.rast dgm1km
100%

with PROJ_INFO
name: Krovakxy
datum: hermannskogel
dx: 653.000000
dy: -212.000000
dz: 449.000000
proj: krovakyx
ellps: bessel
a: 6377397.1550000003
es: 0.0066743722
f: 299.1528128000

Now Radim and me start to evaluate the error (due to ignored datum
transformation and missing triangulation points for S-JTSK = Krovakyx).

Markus

11

On Thu, May 23, 2002 at 05:36:04AM -0600, Roger Miller wrote:

On Thursday 23 May 2002 02:26, Markus Neteler wrote:

> Following fix cures the problem for env.c:
> cvs diff -u env.c
> RCS file: /grassrepository/grass/src/libes/gis/env.c,v
> retrieving revision 1.5
> diff -u -r1.5 env.c
> --- env.c 12 May 2002 12:04:45 -0000 1.5
> +++ env.c 23 May 2002 08:25:33 -0000
> @@ -177,13 +177,12 @@
> int n;
>
> for (n = 0; n < count; n++)
> - if (env[n].name && (strcmp(env[n].name, name)==0))
> + if (env[n].name && (strlen(name)!=0) && (strcmp(env[n].name,
> name)==0)) {
> free (env[n].name);
> env[n].name = 0;
> return 1;
> }
> -
> return 0;
> }
>
> Objections to submit this fix?

Markus, if an empty string caused the problem, then maybe a better fix would
be to change set_env so that an empty string never stored. An empty string
could be treated like a NULL.

At line 125 in env.c the statement

if(!value)

could be changed to

if(!value || !strlen(value))

That way an empty string is treated the same way as sending a NULL string and
causes GRASS to unset the environment variable.

This change is working - I have reverted mine and submitted yours to
CVS.

> But...
> Then the next bug occurs due to the new NAD datum support:
> In r.proj/main.c line 279 is the function G_database_datum_name() used:
> strncpy(in_datum,G_database_datum_name(),sizeof(in_datum));
> For my existing locations it returns NULL which causes a crash
> of strncpy(). The function G_database_datum_name() is in
> src/libes/gis/proj3.c
>
> How to solve that one (hi Roger)? Therefore [vs].proj are also affected.

Uhh. I guess I did know about that problem. A check is easily added. My
preference would be also to change G_database_datum_name() so that it does
not return NULL (maybe returning a pointer to "unknown" instead) and/or
ensuring that the datum is never blank.

Latter is not possible (backward compatibility, since map datum recording
was implemented not too long ago). Please submit the proposed fix (check).

Thanks,

Markus

12

Markus Neteler wrote:

Following fix cures the problem for env.c:
cvs diff -u env.c
RCS file: /grassrepository/grass/src/libes/gis/env.c,v
retrieving revision 1.5
diff -u -r1.5 env.c
--- env.c 12 May 2002 12:04:45 -0000 1.5
+++ env.c 23 May 2002 08:25:33 -0000
@@ -177,13 +177,12 @@
     int n;

     for (n = 0; n < count; n++)
- if (env[n].name && (strcmp(env[n].name, name)==0))
+ if (env[n].name && (strlen(name)!=0) && (strcmp(env[n].name, name)==0))
        {
            free (env[n].name);
            env[n].name = 0;
            return 1;
        }
-
     return 0;
}

Objections to submit this fix?

This doesn't make any sense. What is the nature of the problem which
this is meant to fix?

--
Glynn Clements <glynn.clements@virgin.net>

13

Roger Miller wrote:

> But...
> Then the next bug occurs due to the new NAD datum support:
> In r.proj/main.c line 279 is the function G_database_datum_name() used:
> strncpy(in_datum,G_database_datum_name(),sizeof(in_datum));
> For my existing locations it returns NULL which causes a crash
> of strncpy(). The function G_database_datum_name() is in
> src/libes/gis/proj3.c
>
> How to solve that one (hi Roger)? Therefore [vs].proj are also affected.

Uhh. I guess I did know about that problem. A check is easily added. My
preference would be also to change G_database_datum_name() so that it does
not return NULL (maybe returning a pointer to "unknown" instead) and/or
ensuring that the datum is never blank.

That will only work if the value is acceptable to set_datumshift(), or
you explicitly check the value within *.proj. Ditto for the ellipse
name.

proj_f should probably be initialised to pj_do_proj, so that you can
just omit the call to set_datumshift() if you don't have the necessary
parameters.

--
Glynn Clements <glynn.clements@virgin.net>

14

On Thu, May 23, 2002 at 04:29:01PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> Following fix cures the problem for env.c:
> cvs diff -u env.c
> RCS file: /grassrepository/grass/src/libes/gis/env.c,v
> retrieving revision 1.5
> diff -u -r1.5 env.c
> --- env.c 12 May 2002 12:04:45 -0000 1.5
> +++ env.c 23 May 2002 08:25:33 -0000
> @@ -177,13 +177,12 @@
> int n;
>
> for (n = 0; n < count; n++)
> - if (env[n].name && (strcmp(env[n].name, name)==0))
> + if (env[n].name && (strlen(name)!=0) && (strcmp(env[n].name, name)==0))
> {
> free (env[n].name);
> env[n].name = 0;
> return 1;
> }
> -
> return 0;
> }
>
> Objections to submit this fix?

This doesn't make any sense. What is the nature of the problem which
this is meant to fix?

Meanwhile the fix by Roger Miller is submitted to env.c.

Markus

15

Roger Miller wrote:

Markus, if an empty string caused the problem, then maybe a better fix would
be to change set_env so that an empty string never stored. An empty string
could be treated like a NULL.

At line 125 in env.c the statement

if(!value)

could be changed to

if(!value || !strlen(value))

That way an empty string is treated the same way as sending a NULL string and
causes GRASS to unset the environment variable.

This should already be handled by the lines which follow:

    tv = G_store (value);
    G_strip (tv);
    if (*tv == 0)
    {
  free (tv);
  unset_env (name);
  return 1;
    }

--
Glynn Clements <glynn.clements@virgin.net>