[GRASSLIST:2164] r.in.gdal : Unresolvable problems?

GRASS GRASS user
,
1

Hi, folks.

I've been away from the list and GRASS in general for a little while.
Last time I used GRASS, I was having problems with r.in.gdal
segfaulting when I tried to import DEMs.

I have a renewed interest in GIS and wanted to play around with GRASS
some more. I downloaded the binary version of Grass (5.0.2) and
installed it on Knoppix (a Debian-based Live-CD). GRASS ran okay, but
I had the same old segfault problem. I searched the mailing list and
found that the solution which has worked for others is to compile
grass from source with --with-gdal. I downloaded the source (5.0.3)
and compiled it on my Redhat 8.0 box--I already had gdal-1.1.9
installed. It compiled without errors, but I still had the segfault
problem. Here are some things I've tried, all ending with the same
result:

* Remove gdal from my system and install the binary version of GRASS.
* Uninstall the binary version, compile gdal-1.1.8 and compile GRASS
  5.0.3 with --with-gdal.
* Uninstall (gdal and GRASS), install gdal-1.1.9 and compile GRASS
  5.0.3 with --with-gdal
* At some point, I tried using GRASS 5.0.2, but that didn't work
  either.
* Install the binary version of GRASS 5.0.2 and replace (symlink) the
  GRASS version of libgdal.1.1.so with the one installed with gdal.

Note that the gdal utility programs seem to work fine. It's just
r.in.gdal that crashes and burns.

Here is an example of a DEM and a DRG each of which crash r.in.gdal:
ftp://gisweb1.radford.edu/dem/DEMs/36080/36080G5.zip
ftp://gisweb1.radford.edu/drgs/o36080g5.zip

And I've attached the output from running strace on r.in.gdal when it
segfaults. What are all the windoze-style paths in there for? (I
gzipped the output so it wasn't so large.)

This problem has rendered GRASS relatively useless to me because all
my data is in formats which need r.in.gdal to import them! :frowning: And
the frustrating thing is that it used to all work. Many moons ago, I
compiled 5.0.2 and gdal-1.1.8 from source and r.in.gdal worked. Then
it suddenly stopped for some reason and I haven't been able to get it
to work since. (I don't think upgraded anything between the time it
worked and stopped working...but I could be wrong.)

I'd really 'preciate any help anyone could give. I've tried
everything I could think of and find on the lists.

Thanks,
Ben

--
Ben Logan
Google Answers Researcher
answers.google.com
When you're searching for information, Google Answers.

OpenPGP Key ID: A1ADD1F0
Fingerprint: E32C 1CF9 C2FE DFC9 BB5C A24F 57DB 5679 A1AD D1F0
Get it from http://cyclist.wblogan.net/benlogan.gpg

(attachments)

output.gz (5.15 KB)

2

Ben,

I have downloaded o36080g5.zip map and imported without
problems using

- GRASS 5.3-CVS
- GDAL-CVS
- compiled GRASS with --with-gdal

My suggestion is to polish the system and eliminate all
GDAL libs. Probably there are different versions in
different directories? Check out for
- gdal.a
- libgdal*
- ogr*
  etc

Good luck

Markus

On Thu, Jan 08, 2004 at 03:10:41PM -0500, Ben Logan wrote:

Hi, folks.

I've been away from the list and GRASS in general for a little while.
Last time I used GRASS, I was having problems with r.in.gdal
segfaulting when I tried to import DEMs.

I have a renewed interest in GIS and wanted to play around with GRASS
some more. I downloaded the binary version of Grass (5.0.2) and
installed it on Knoppix (a Debian-based Live-CD). GRASS ran okay, but
I had the same old segfault problem. I searched the mailing list and
found that the solution which has worked for others is to compile
grass from source with --with-gdal. I downloaded the source (5.0.3)
and compiled it on my Redhat 8.0 box--I already had gdal-1.1.9
installed. It compiled without errors, but I still had the segfault
problem. Here are some things I've tried, all ending with the same
result:

* Remove gdal from my system and install the binary version of GRASS.
* Uninstall the binary version, compile gdal-1.1.8 and compile GRASS
  5.0.3 with --with-gdal.
* Uninstall (gdal and GRASS), install gdal-1.1.9 and compile GRASS
  5.0.3 with --with-gdal
* At some point, I tried using GRASS 5.0.2, but that didn't work
  either.
* Install the binary version of GRASS 5.0.2 and replace (symlink) the
  GRASS version of libgdal.1.1.so with the one installed with gdal.

Note that the gdal utility programs seem to work fine. It's just
r.in.gdal that crashes and burns.

Here is an example of a DEM and a DRG each of which crash r.in.gdal:
ftp://gisweb1.radford.edu/dem/DEMs/36080/36080G5.zip
ftp://gisweb1.radford.edu/drgs/o36080g5.zip

And I've attached the output from running strace on r.in.gdal when it
segfaults. What are all the windoze-style paths in there for? (I
gzipped the output so it wasn't so large.)

This problem has rendered GRASS relatively useless to me because all
my data is in formats which need r.in.gdal to import them! :frowning: And
the frustrating thing is that it used to all work. Many moons ago, I
compiled 5.0.2 and gdal-1.1.8 from source and r.in.gdal worked. Then
it suddenly stopped for some reason and I haven't been able to get it
to work since. (I don't think upgraded anything between the time it
worked and stopped working...but I could be wrong.)

I'd really 'preciate any help anyone could give. I've tried
everything I could think of and find on the lists.

Thanks,
Ben

--
Ben Logan
Google Answers Researcher
answers.google.com
When you're searching for information, Google Answers.

OpenPGP Key ID: A1ADD1F0
Fingerprint: E32C 1CF9 C2FE DFC9 BB5C A24F 57DB 5679 A1AD D1F0
Get it from http://cyclist.wblogan.net/benlogan.gpg

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

3

On Fri, Jan 09, 2004 at 09:29:45AM +0100, Markus Neteler wrote:

Ben,

I have downloaded o36080g5.zip map and imported without
problems using

- GRASS 5.3-CVS
- GDAL-CVS
- compiled GRASS with --with-gdal

My suggestion is to polish the system and eliminate all
GDAL libs. Probably there are different versions in
different directories? Check out for
- gdal.a
- libgdal*
- ogr*
  etc

Hi, Markus. Thanks for responding.

This morning I ran 'find' from the root of my filesystem and searched
for anything named gdal* libgdal* or ogr*. I removed everything (gdal
related) that turned up, removed the grass installation and sources
and removed the gdal sources. I then compiled gdal-1.1.9, and grass
5.0.3 using --with-gdal (and also --without-fftw, but I'm assuming
that shouldn't affect it). I had the same problem as before.

As soon as I can get to a fast connection, I'll grab the CVS versions
of grass and gdal and try again. If that doesn't work, I'll really be
lost. I was hoping to get it working soon because I'm trying to
create a Knoppix-based GRASS demo cd using data from my area. I want
to make several copies and distribute them at my community college
because I think it would be a great way to let people play with grass
and see what it can do without having to know how to set it
up...especially since most people don't run *nix.

I'll let you know if the CVS version works or not. Any ideas if it
doesn't?

Thanks,
Ben

--
Ben Logan
Google Answers Researcher
answers.google.com
When you're searching for information, Google Answers.

OpenPGP Key ID: A1ADD1F0
Fingerprint: E32C 1CF9 C2FE DFC9 BB5C A24F 57DB 5679 A1AD D1F0
Get it from http://cyclist.wblogan.net/benlogan.gpg

4

Ben Logan wrote:

This morning I ran 'find' from the root of my filesystem and searched
for anything named gdal* libgdal* or ogr*. I removed everything (gdal
related) that turned up, removed the grass installation and sources
and removed the gdal sources. I then compiled gdal-1.1.9, and grass
5.0.3 using --with-gdal (and also --without-fftw, but I'm assuming
that shouldn't affect it). I had the same problem as before.

One comment: when building GDAL for use with GRASS, it may help to use
the --without-grass configure switch.

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

5

On Fri, Jan 09, 2004 at 05:45:31PM +0000, Glynn Clements wrote:

Ben Logan wrote:

> This morning I ran 'find' from the root of my filesystem and searched
> for anything named gdal* libgdal* or ogr*. I removed everything (gdal
> related) that turned up, removed the grass installation and sources
> and removed the gdal sources. I then compiled gdal-1.1.9, and grass
> 5.0.3 using --with-gdal (and also --without-fftw, but I'm assuming
> that shouldn't affect it). I had the same problem as before.

One comment: when building GDAL for use with GRASS, it may help to use
the --without-grass configure switch.

Glynn,

Thanks for the suggestion. I tried doing as you said. First, I
totally uninstalled the gdal libs (and includes) from my system and
then recompiled with --without-grass. Then I tried running r.in.gdal
again (without recompiling grass). It still segfaulted, so I removed
my grass installation and recompiled it (using --with-gdal). Still
failed. One thing I noted was that there are two versions of
r.in.gdal--one in /usr/local/grass5/etc/bin/cmd and one in
/usr/local/grass5/bin. They differ (the one under etc is quite a bit
larger), and the one under bin is the one which gets run under GRASS,
but I tried running the other and it failed too.

I'm starting to see red right now, so I think I'll give it a rest for
today. :slight_smile: I have installed Knoppix on my HD so I can remaster it, so
tomorrow I will try compiling grass and gdal under Knoppix. That's a
brand spankin' knew development environment, so there's no possibility
that there are any old libs lying around etc. If that doesn't work,
I'll really be lost....something tells me it isn't going to work
either. If someone can help me make sense of it, I'll run gdb on
r.in.gdal. I don't know much C/C++, so I'll need some help.

Take care,
Ben

--
Ben Logan
Google Answers Researcher
answers.google.com
When you're searching for information, Google Answers.

OpenPGP Key ID: A1ADD1F0
Fingerprint: E32C 1CF9 C2FE DFC9 BB5C A24F 57DB 5679 A1AD D1F0
Get it from http://cyclist.wblogan.net/benlogan.gpg

6

Ben Logan wrote:

> > This morning I ran 'find' from the root of my filesystem and searched
> > for anything named gdal* libgdal* or ogr*. I removed everything (gdal
> > related) that turned up, removed the grass installation and sources
> > and removed the gdal sources. I then compiled gdal-1.1.9, and grass
> > 5.0.3 using --with-gdal (and also --without-fftw, but I'm assuming
> > that shouldn't affect it). I had the same problem as before.
>
> One comment: when building GDAL for use with GRASS, it may help to use
> the --without-grass configure switch.

Thanks for the suggestion. I tried doing as you said. First, I
totally uninstalled the gdal libs (and includes) from my system and
then recompiled with --without-grass. Then I tried running r.in.gdal
again (without recompiling grass). It still segfaulted, so I removed
my grass installation and recompiled it (using --with-gdal). Still
failed. One thing I noted was that there are two versions of
r.in.gdal--one in /usr/local/grass5/etc/bin/cmd and one in
/usr/local/grass5/bin. They differ (the one under etc is quite a bit
larger), and the one under bin is the one which gets run under GRASS,
but I tried running the other and it failed too.

Almost everything in the bin directory is a (hard) link to
etc/front.end. The "real" programs live in etc/bin/cmd and
etc/bin/inter.

front.end simply determines whether to run the "cmd" or "inter"
version, depending upon which exists, and whether any arguments were
given. This allows a module to have separate command-line and
interactive versions.

I'm starting to see red right now, so I think I'll give it a rest for
today. :slight_smile: I have installed Knoppix on my HD so I can remaster it, so
tomorrow I will try compiling grass and gdal under Knoppix. That's a
brand spankin' knew development environment, so there's no possibility
that there are any old libs lying around etc. If that doesn't work,
I'll really be lost....something tells me it isn't going to work
either. If someone can help me make sense of it, I'll run gdb on
r.in.gdal. I don't know much C/C++, so I'll need some help.

Some other thing which might make a difference are linking r.in.gdal
with g++ instead of gcc, using an earlier version of GDAL, and
disabling optimisation.

r.in.gdal itself is a fairly simple program. OTOH, the GDAL library is
complex, and is written in C++ (which greatly increases the potential
for problems). Consequently, any problems are far more likely to be in
GDAL than in r.in.gdal (provided that you are using --with-gdal; the
dynamic loading option can be problematic).

As for debugging:

1. Run gdb on /usr/local/grass5/etc/bin/cmd/r.in.gdal rather than just
r.in.gdal, as the latter is just the front.end program.

2. Make sure that both r.in.gdal and the GDAL library were built with
debug info (-g), and preferably without optimisation. This can usually
be achieved by using "CFLAGS=-g ./configure ..." when configuring the
package in question (the default is "-g -O2", which enables
optimisation; this can complicate debugging, as the resulting code
often bears little resemblance to the source code).

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

7

On Sat, Jan 10, 2004 at 08:09:59PM +0000, Glynn Clements wrote:

Almost everything in the bin directory is a (hard) link to
etc/front.end. The "real" programs live in etc/bin/cmd and
etc/bin/inter.

front.end simply determines whether to run the "cmd" or "inter"
version, depending upon which exists, and whether any arguments were
given. This allows a module to have separate command-line and
interactive versions.

Okay, that makes sense.

Some other thing which might make a difference are linking r.in.gdal
with g++ instead of gcc, using an earlier version of GDAL, and
disabling optimisation.

r.in.gdal itself is a fairly simple program. OTOH, the GDAL library is
complex, and is written in C++ (which greatly increases the potential
for problems). Consequently, any problems are far more likely to be in
GDAL than in r.in.gdal (provided that you are using --with-gdal; the
dynamic loading option can be problematic).

As for debugging:

1. Run gdb on /usr/local/grass5/etc/bin/cmd/r.in.gdal rather than just
r.in.gdal, as the latter is just the front.end program.

2. Make sure that both r.in.gdal and the GDAL library were built with
debug info (-g), and preferably without optimisation. This can usually
be achieved by using "CFLAGS=-g ./configure ..." when configuring the
package in question (the default is "-g -O2", which enables
optimisation; this can complicate debugging, as the resulting code
often bears little resemblance to the source code).

Thank you very much for your help, Glynn. It must have been the
optimisation that was causing problems because I recompiled with -g
like you said, and it works fine. Now I have a question about one of
the maps that was imported, but I'll start another thread for it. :slight_smile:

Best regards,
Ben

--
Ben Logan
Google Answers Researcher
answers.google.com
When you're searching for information, Google Answers.

OpenPGP Key ID: A1ADD1F0
Fingerprint: E32C 1CF9 C2FE DFC9 BB5C A24F 57DB 5679 A1AD D1F0
Get it from http://cyclist.wblogan.net/benlogan.gpg

8

Hi Ben,

Did you try grass5.0.1 from its source code?
I had similar problem (segfault of r.in.gdal of grass5.0.3
compiled from its source code on RedHat 8.0 and RedHat9) but
now my r.in.gdal is working after I replaced it with 5.0.1.

---------------------------------------
Kenlo Nishida
Institute of Agricultural and Forest Engineering
University of Tsukuba, Japan 305-8572
kenlo@sakura.cc.tsukuba.ac.jp

9

So is there a working step-by-step procedure?
I have tried the recommended fixes without success up to this point.
As I understand it now, I should:

Uninstall gdal, but gdal does not have a "make uninstall".
What should I delete?

for gdal:
CFLAGS=-g ./configure --without-grass

For GRASS:
CFLAGS=-g ./configure --with-gdal=/usr/local/bin (where gdal-config is located)

Then build gdal again with:
CFLAGS=-g ./configure --with-grass=???

The gdal configure --help says to point it to the "libgrass path", but
libgrass does not exist.

--
Carl Brown
Whitefield, NH USA
-----

10

Hello
I'm not sure what your exact problem was here but I spent some time
investigating the r.in.gdal segmentation fault problem a few months ago
and so can offer some contents.

On Wed, 21 Jan 2004, Carl Brown wrote:

So is there a working step-by-step procedure?
I have tried the recommended fixes without success up to this point.
As I understand it now, I should:

Uninstall gdal, but gdal does not have a "make uninstall".
What should I delete?

I don't see any reason why you should need to uninstall GDAL. And even if
you are upgrading to a new version just install it in the same place and
it will over write the files. The important thing is the 'gdal-config' for
the installation you wish to use. GRASS uses this during compilation to
tell it the correct names of the GDAL libraries and where to look for them
and the header files.

for gdal:
CFLAGS=-g ./configure --without-grass

That looks fine I think

For GRASS:
CFLAGS=-g ./configure --with-gdal=/usr/local/bin (where gdal-config is located)

That isn't right. If gdal-config is in your PATH then just use
--with-gdal, otherwise the argument after the sign should be the full path
to gdal-config, i.e. in your example above it should be
--with-gdal=/usr/local/bin/gdal-config . But if /usr/local/bin is already
in your path then this is not necessary.

Then build gdal again with:
CFLAGS=-g ./configure --with-grass=???

Well that won't be necessary for use with GRASS and might even break
things if the installed GDAL is no longer the same as the one you compiled
GRASS against *I'm not 100% sure about that). If you need the libgrass
support in GDAL you could maybe keep two separate GDAL installations, one
(without libgrass support) for use with GRASS and another (with libgrass
support) for use with other programs that needed to read GRASS rasters
through GDAL. The argument to --with-gdal would then be more relevant when
compiling GRASS.

The gdal configure --help says to point it to the "libgrass path", but
libgrass does not exist.

Well if you haven't installed libgrass and don't need it then don't try to
compile GDAL with libgrass support.

I hope some of the above might help put you on the right track.

Paul K

11

On Wednesday 21 January 2004 15:25, Paul Kelly wrote:

Hello
I'm not sure what your exact problem was here but I spent some time
investigating the r.in.gdal segmentation fault problem a few months ago

I had the dreaded segfault problem. It had occurred on this particular system
since GRASS was first installed many moons ago. It is now fixed!!!
Thanks, Paul!

What I did, step by step:

CVS update both GRASS and gdal to:
GRASS 5.0.3
gdal 1.1.9

$ find /usr/local -name *gdal*

Delete all relevant results.

$ find /usr/local -name *ogr*

Delete all relevant results.

$ cd {gdal source directory}
$ make clean
$ ./configure --without-grass
$ make
$ su
# make install
# exit
$ cd {grass source directory}
$ make clean
$ ./configure --with-gdal
$ make
$ su
# make install
# exit

--
Carl Brown
Whitefield, NH USA
-----