Details Ticket 1052


Comment | Reply | Take | Open


Serial Number 1052
Subject [rsv].proj are crashing
Area bug
Queue grass
Requestors neteler@itc.it
Owner none
Status resolved
Last User Contact Wed Jun 5 16:00:19 2002 (6 yr ago)
Current Priority 70
Final Priority 70
Due No date assigned
Last Action Thu Nov 7 18:59:26 2002 (6 yr ago)
Created Wed May 22 11:22:15 2002 (6 yr ago)

Transaction History Ticket 1052


Wed, May 22 2002 11:22:15    Request created by guest  
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).

This should be fixed before pre5.

Markus
Wed, May 22 2002 17:57:17    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <15595.44656.427284.128072@cerise.nosuchdomain.co.uk>
Date Wed, 22 May 2002 15:42:56 +0100
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #1052] (grass) [rsv].proj are crashing
In-Reply-To <20020522092215.9D8F213A19@lists.intevation.de>
References <20020522092215.9D8F213A19@lists.intevation.de>
X-Mailer VM 6.94 under 21.4 (patch 4) "Artificial Intelligence (candidate #1)" XEmacs Lucid
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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.

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


Wed, May 22 2002 18:07:00    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 22 May 2002 18:06:53 +0200
From Markus Neteler <neteler@itc.it>
To Glynn Clements via RT <grass-bugs@intevation.de>
Cc grass5 developers list <grass5@grass.itc.it>
Subject Re: [bug #1052] (grass) [rsv].proj are crashing
Message-ID <20020522180653.S13771@itc.it>
Mail-Followup-To Glynn Clements via RT <grass-bugs@intevation.de>, grass5 developers list <grass5@grass.itc.it>
References <20020522155717.B8F4713A19@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <20020522155717.B8F4713A19@lists.intevation.de>; from grass-bugs@intevation.de on Wed, May 22, 2002 at 05:57:17PM +0200
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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


Wed, May 22 2002 18:13:00    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 22 May 2002 18:12:55 +0200
From Markus Neteler <neteler@itc.it>
To grass5 developers list <grass5@grass.itc.it>
Cc Glynn Clements via RT <grass-bugs@intevation.de>
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
Message-ID <20020522181255.T13771@itc.it>
Mail-Followup-To grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
References <20020522155717.B8F4713A19@lists.intevation.de> <20020522180653.S13771@itc.it>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <20020522180653.S13771@itc.it>; from neteler@itc.it on Wed, May 22, 2002 at 06:06:53PM +0200
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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


Thu, May 23 2002 00:46:36    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <15596.7844.246972.912984@cerise.nosuchdomain.co.uk>
Date Wed, 22 May 2002 23:41:40 +0100
To Markus Neteler <neteler@itc.it>
Cc grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
In-Reply-To <20020522181255.T13771@itc.it>
References <20020522155717.B8F4713A19@lists.intevation.de> <20020522180653.S13771@itc.it> <20020522181255.T13771@itc.it>
X-Mailer VM 6.94 under 21.4 (patch 4) "Artificial Intelligence (candidate #1)" XEmacs Lucid
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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>


Thu, May 23 2002 10:26:17    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 23 May 2002 10:26:14 +0200
From Markus Neteler <neteler@itc.it>
To Glynn Clements <glynn.clements@virgin.net>
Cc grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
Message-ID <20020523102614.D26804@itc.it>
Mail-Followup-To Glynn Clements <glynn.clements@virgin.net>, grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
References <20020522155717.B8F4713A19@lists.intevation.de> <20020522180653.S13771@itc.it> <20020522181255.T13771@itc.it> <15596.7844.246972.912984@cerise.nosuchdomain.co.uk>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <15596.7844.246972.912984@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Wed, May 22, 2002 at 11:41:40PM +0100
X-Spam-Status No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20
X-Spam-Level
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


Thu, May 23 2002 10:32:22    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 23 May 2002 10:32:20 +0200
From Markus Neteler <neteler@itc.it>
To grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
Message-ID <20020523103220.E26804@itc.it>
Mail-Followup-To grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
References <20020522155717.B8F4713A19@lists.intevation.de> <20020522180653.S13771@itc.it> <20020522181255.T13771@itc.it> <15596.7844.246972.912984@cerise.nosuchdomain.co.uk> <20020523102614.D26804@itc.it>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <20020523102614.D26804@itc.it>; from neteler@itc.it on Thu, May 23, 2002 at 10:26:14AM +0200
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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).


Thu, May 23 2002 11:46:24    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 23 May 2002 11:46:21 +0200
From Markus Neteler <neteler@itc.it>
To grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
Message-ID <20020523114621.G26804@itc.it>
Mail-Followup-To grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
References <20020522155717.B8F4713A19@lists.intevation.de> <20020522180653.S13771@itc.it> <20020522181255.T13771@itc.it> <15596.7844.246972.912984@cerise.nosuchdomain.co.uk> <20020523102614.D26804@itc.it> <20020523103220.E26804@itc.it>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <20020523103220.E26804@itc.it>; from neteler@itc.it on Thu, May 23, 2002 at 10:32:20AM +0200
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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


Thu, May 23 2002 13:31:19    Mail sent by morten@ngb.se  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Resent-Message-Id <200205231131.g4NBV5F02492@thuille.itc.it.>
From Morten Hulden <morten@ngb.se>
To grass5 developers list <grass5@grass.itc.it>
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
In-Reply-To <20020523114621.G26804@itc.it>
Message-ID <Pine.LNX.4.44.0205231241450.18339-100000@tor.ngb.se>
MIME-Version 1.0
Content-Type TEXT/PLAIN; charset=US-ASCII
Sender grass5-admin@grass.itc.it
Errors-To grass5-admin@grass.itc.it
X-BeenThere grass5@grass.itc.it
X-Mailman-Version 2.0.5
Precedence bulk
List-Help <mailto:grass5-request@grass.itc.it?subject=help>
List-Post <mailto:grass5@grass.itc.it>
List-Subscribe <http://grass.itc.it/mailman/listinfo/grass5>, <mailto:grass5-request@grass.itc.it?subject=subscribe>
List-Id GRASS 5 Developers mailing list <grass5.grass.itc.it>
List-Unsubscribe <http://grass.itc.it/mailman/listinfo/grass5>, <mailto:grass5-request@grass.itc.it?subject=unsubscribe>
List-Archive <http://grass.itc.it/pipermail/grass5/>
Date Thu, 23 May 2002 12:52:12 +0200 (CEST)
Resent-From neteler@itc.it
Resent-Date Thu, 23 May 2002 13:31:05 +0200
Resent-To grass-bugs@intevation.de
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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


_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5


Thu, May 23 2002 13:59:20    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 23 May 2002 13:59:13 +0200
From Markus Neteler <neteler@itc.it>
To Morten Hulden <morten@ngb.se>
Cc grass5 developers list <grass5@grass.itc.it>, grass-bugs@intevation.de
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
Message-ID <20020523135913.I26804@itc.it>
Mail-Followup-To Morten Hulden <morten@ngb.se>, grass5 developers list <grass5@grass.itc.it>, grass-bugs@intevation.de
References <20020523114621.G26804@itc.it> <Pine.LNX.4.44.0205231241450.18339-100000@tor.ngb.se>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <Pine.LNX.4.44.0205231241450.18339-100000@tor.ngb.se>; from morten@ngb.se on Thu, May 23, 2002 at 12:52:12PM +0200
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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.


Thu, May 23 2002 15:41:07    Mail sent by rgrmill@rt66.com  
Return-Path <rgrmill@rt66.com>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <B0012648683@BYHU.star2.net>
Content-Type text/plain; charset="iso-8859-1"
From Roger Miller <rgrmill@rt66.com>
Reply-To rgrmill@rt66.com
To Markus Neteler <neteler@itc.it>, Glynn Clements <glynn.clements@virgin.net>
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
Date Thu, 23 May 2002 05:36:04 -0600
X-Mailer KMail [version 1.3.1]
Cc grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
References <20020522155717.B8F4713A19@lists.intevation.de> <15596.7844.246972.912984@cerise.nosuchdomain.co.uk> <20020523102614.D26804@itc.it>
In-Reply-To <20020523102614.D26804@itc.it>
Organization home
MIME-Version 1.0
Content-Transfer-Encoding 8bit
X-Spam-Status No, hits=-2.4 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM version=2.20
X-Spam-Level
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


Thu, May 23 2002 15:55:57    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 23 May 2002 15:55:53 +0200
From Markus Neteler <neteler@itc.it>
To grass5 developers list <grass5@grass.itc.it>
Cc grass-bugs@intevation.de
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
Message-ID <20020523155553.M26804@itc.it>
Mail-Followup-To grass5 developers list <grass5@grass.itc.it>, grass-bugs@intevation.de
References <20020523114621.G26804@itc.it> <Pine.LNX.4.44.0205231241450.18339-100000@tor.ngb.se>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <Pine.LNX.4.44.0205231241450.18339-100000@tor.ngb.se>; from morten@ngb.se on Thu, May 23, 2002 at 12:52:12PM +0200
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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


Thu, May 23 2002 17:14:47    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 23 May 2002 17:14:41 +0200
From Markus Neteler <neteler@itc.it>
To Roger Miller <rgrmill@rt66.com>
Cc Glynn Clements <glynn.clements@virgin.net>, grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
Message-ID <20020523171441.R26804@itc.it>
Mail-Followup-To Roger Miller <rgrmill@rt66.com>, Glynn Clements <glynn.clements@virgin.net>, grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
References <20020522155717.B8F4713A19@lists.intevation.de> <15596.7844.246972.912984@cerise.nosuchdomain.co.uk> <20020523102614.D26804@itc.it> <B0012648683@BYHU.star2.net>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <B0012648683@BYHU.star2.net>; from rgrmill@rt66.com on Thu, May 23, 2002 at 05:36:04AM -0600
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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


Thu, May 23 2002 18:07:20    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <15597.2749.269205.362612@cerise.nosuchdomain.co.uk>
Date Thu, 23 May 2002 16:29:01 +0100
To Markus Neteler <neteler@itc.it>
Cc grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
In-Reply-To <20020523102614.D26804@itc.it>
References <20020522155717.B8F4713A19@lists.intevation.de> <20020522180653.S13771@itc.it> <20020522181255.T13771@itc.it> <15596.7844.246972.912984@cerise.nosuchdomain.co.uk> <20020523102614.D26804@itc.it>
X-Mailer VM 6.94 under 21.4 (patch 4) "Artificial Intelligence (candidate #1)" XEmacs Lucid
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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>


Thu, May 23 2002 18:10:04    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 23 May 2002 18:10:00 +0200
From Markus Neteler <neteler@itc.it>
To Glynn Clements <glynn.clements@virgin.net>
Cc grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
Subject Re: [GRASS5] Re: [bug #1052] (grass) [rsv].proj are crashing
Message-ID <20020523181000.X26804@itc.it>
Mail-Followup-To Glynn Clements <glynn.clements@virgin.net>, grass5 developers list <grass5@grass.itc.it>, Glynn Clements via RT <grass-bugs@intevation.de>
References <20020522155717.B8F4713A19@lists.intevation.de> <20020522180653.S13771@itc.it> <20020522181255.T13771@itc.it> <15596.7844.246972.912984@cerise.nosuchdomain.co.uk> <20020523102614.D26804@itc.it> <15597.2749.269205.362612@cerise.nosuchdomain.co.uk>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <15597.2749.269205.362612@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Thu, May 23, 2002 at 04:29:01PM +0100
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
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


Fri, May 24 2002 09:18:05    Mail sent by egm2@jps.net  
Return-Path <egm2@jps.net>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 24 May 2002 00:19:19 -0700
From "Eric G. Miller" <egm2@jps.net>
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #1052] (grass) [rsv].proj are crashing
Message-ID <20020524071919.GA2069@calico.local>
Mail-Followup-To Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20020522092215.9D8F213A19@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20020522092215.9D8F213A19@lists.intevation.de>
User-Agent Mutt/1.3.28i
Sender "Eric G. Miller" <egm2@jps.net>
X-Spam-Status No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level
On Wed, May 22, 2002 at 11:22:15AM +0200, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=1052
> -------------------------------------------------------------------------
> 
> 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).
> 
> This should be fixed before pre5.

r.proj at least does these dubious thing:

   strncpy (in_datum, G_database_datum_name(), sizeof(in_datum));
   strncpy (in_ellipse, G_database_ellipse_name(), sizeof(in_ellipse));

Since both the datum and ellipse functions can return NULL, strncpy
will invoke undefined behavior in those cases.  For me, the segfault
in r.proj disappears, by handling these better.

Now, if I can figure out why "1" is returned as the projection name for
UTM...

-- 
Eric G. Miller <egm2@jps.net>


Wed, Jun 5 2002 15:58:46    Mail sent by guest  
seems to be fixed.
Wed, Jun 5 2002 16:00:19    Mail sent by mneteler  
in HEAD it is fixed. Needs verification for branch.

Markus
Thu, Nov 7 2002 18:59:26    Status changed to resolved by mneteler  
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request