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
|
|
|
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
|
|