[GRASSLIST:2333] r.in.gdal segfault

Hello list,

I have some problems with "r.in.gdal":
I run grass 5.0.3, compiled with the "--with-gdal" option, on a SuSE8.2 box.
The gdal version is 1.1.9, compiled with "--without-jasper" and
"--without-grass" options. [Both compiled OK, from 'clean' sources (viz,
after a make distclean eachtime)]

I try to import this ASCII DEM:
http://new-gis.mannlib.cornell.edu/CUGIR_Data/data1/x42elu.dem.gz
When I run
r.in.gdal i=x42elu.dem o=dem lo=x42
I get a segmentation fault.
Other formats seem to be imported without trouble (GeoTIFF, for example).
FYI, the same file is imported without trouble on a SuSE7.1 box, with
grass5.0.2 and gdal1.1.9.

Any idea of troubleshooting more than welcome, it's rather frustrating...
Thanks in advance
P.
--
Soil & Water Laboratory
Dept. of Biological & Environmental Engineering
Cornell University
ITHACA, NY 14853
Tel: (607)255.2463

On Thu, Jan 22, 2004 at 08:15:19PM -0500, SWlab wrote:

Hello list,

I have some problems with "r.in.gdal":
I run grass 5.0.3, compiled with the "--with-gdal" option, on a SuSE8.2 box.
The gdal version is 1.1.9, compiled with "--without-jasper" and
"--without-grass" options. [Both compiled OK, from 'clean' sources (viz,
after a make distclean eachtime)]

I try to import this ASCII DEM:
http://new-gis.mannlib.cornell.edu/CUGIR_Data/data1/x42elu.dem.gz
When I run
r.in.gdal i=x42elu.dem o=dem lo=x42
I get a segmentation fault.

Did you try 'gdalinfo'?

I have downloaded the file, and it reports:

gdalinfo x42elu.dem
Driver: USGSDEM/USGS Optional ASCII DEM
Size is 1041, 1395
Coordinate System is:
PROJCS["UTM Zone 18, Northern Hemisphere",
    GEOGCS["NAD27",
        DATUM["North_American_Datum_1927",
            SPHEROID["Clarke 1866",6378206.4,294.978698213898,
                AUTHORITY["EPSG","7008"]],
            TOWGS84[-3,142,183,0,0,0,0],
            AUTHORITY["EPSG","6267"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9108"]],
        AXIS["Lat",NORTH],
        AXIS["Long",EAST],
        AUTHORITY["EPSG","4267"]],
    PROJECTION["Transverse_Mercator"],
[...]

But, in fact I also get a segmentation fault (r.in.gdal from 5.3-CVS and
GDAL-CVS).

It crashes in wkt_to_grass() in main.c of r.in.gdal (crash
in line 1054: free( pszUnitsName ); ). Actually I don't know
why, maybe it does not fetch the projection info properly.

Other formats seem to be imported without trouble (GeoTIFF, for example).
FYI, the same file is imported without trouble on a SuSE7.1 box, with
grass5.0.2 and gdal1.1.9.

It seems to be related to USGS DEM only.

gdal_translate -of GTiFF x42elu.dem x42elu.tif
Input file size is 1041, 1395
0...10...20...30...40...50...60...70...80...90...100 - done.

r.in.gdal in=x42elu.tif out=dem loc=demdem
100%
CREATING SUPPORT FILES FOR dem

This works fine. So something runs odd when importing USGS DEM with
r.in.gdal.

Any idea of troubleshooting more than welcome, it's rather frustrating...
Thanks in advance

Unless it is fixed, you may use gdal_translate to convert the map to
GeoTIFF.

Regards

Markus

On Fri, Jan 23, 2004 at 10:34:26AM +0100, Markus Neteler wrote:

It crashes in wkt_to_grass() in main.c of r.in.gdal (crash
in line 1054: free( pszUnitsName ); ). Actually I don't know
why, maybe it does not fetch the projection info properly.

pszUnitsName should not be freed. Remove that line to fix the problem.

            Andrey

--
Andrey V. Kiselev
Home phone: +7 812 5274898 ICQ# 26871517

Hello Andrey

On Fri, 23 Jan 2004, Andrey Kiselev wrote:

On Fri, Jan 23, 2004 at 10:34:26AM +0100, Markus Neteler wrote:
> It crashes in wkt_to_grass() in main.c of r.in.gdal (crash
> in line 1054: free( pszUnitsName ); ). Actually I don't know
> why, maybe it does not fetch the projection info properly.

pszUnitsName should not be freed. Remove that line to fix the problem.

Well done and thank you for finding that long-standing bug. I'm almost
sure it's the one I've been trying to find for several months (re-using
some of the wkt_to_grass code in new functions for 5.7). There
should be a lot more progress on these now.
I have fixed it in CVS.

Thank you!

Paul