[gdal-dev] gdalbuilvrt segmentation fault
Even Rouault
even.rouault at mines-paris.org
Wed Jul 27 07:51:14 EDT 2011
Selon Marco nicoletti <nicoletti at consorzio-innova.it>:
Ok, I've tried with GDAL 1.8.0 and GDAL trunk and it doesn't crash. I haven't
tried with 1.7.0, but it is likely that the bug has been fixed during 1.8
development.
> Dear Even,
>
>
> I sent you two sample dataset whom you can reproduce the error with.
>
> The command line is the following:
>
> $ gdalbuildvrt out.vrt srtm_30m_sample.tif srtm_90m_sample.tif
>
> And it crashes.
>
> Thanks again.
>
> Marco
>
> On Wed, 2011-07-27 at 10:32 +0200, Even Rouault wrote:
> > Selon Marco Nicoletti <nicoletti at consorzio-innova.it>:
> >
> > > Dear Even,
> > >
> > > first of all thanks so much for your reply.
> > > I'm using GDAL 1.7.0 .
> > > You are right about the Data Type; as a matter of fact one DEM is Int16
> and
> > > the other
> > > one is Float32.
> > > The funny thing is that the logging message says that gdalbuildvrt does
> not
> > > support heterogenous
> > > projection instead of saying that the data types are different.
> >
> > Actually, in your example, the WKT strings are not strictly identical if
> you
> > look closely. Versions before 1.8.0 used string comparison which is not
> > appropriate. This has been fixed in GDAL 1.8.0.
> > http://trac.osgeo.org/gdal/ticket/3856
> >
> > I've looked at the changes in gdalbuildvrt between 1.7.0 and the latest
> version,
> > and I don't see any change that could fix the segmentation fault you
> reported
> > originaly. So I'd be interested in how I could replicate this, if you could
> > provide the datasets and the command line that caused the crash.
> >
> > >
> > > I have also experienced that is I change the data type of the first them
> > > using gdal_translate,
> > > then the tool works.
> > >
> > > I attach here the gdalinfo of both DEM files:
> > >
> > > $ gdalbuildvrt ned+srtm.vrt ned/safod+egm96.dem
> srtm/srtm_90m_egm96_grid.tif
> > > 0...10...20...30...40...50...60...70...80...90...100 - done.
> > > Warning 6: gdalbuildvrt does not support heterogenous projection.
> Skipping
> > > srtm/srtm_90m_egm96_grid.tif
> > >
> > > $ gdalinfo ned/safod+egm96.dem
> > > Driver: ENVI/ENVI .hdr Labelled
> > > Files: ned/safod+egm96.dem
> > > ned/safod+egm96.dem.aux.xml
> > > ned/safod+egm96.hdr
> > > Size is 10801, 7201
> > > Coordinate System is:
> > > GEOGCS["WGS 84",
> > > DATUM["WGS_1984",
> > > SPHEROID["WGS 84",6378137,298.257223563,
> > > AUTHORITY["EPSG","7030"]],
> > > TOWGS84[0,0,0,0,0,0,0],
> > > AUTHORITY["EPSG","6326"]],
> > > PRIMEM["Greenwich",0,
> > > AUTHORITY["EPSG","8901"]],
> > > UNIT["degree",0.0174532925199433,
> > > AUTHORITY["EPSG","9108"]],
> > > AUTHORITY["EPSG","4326"]]
> > > Origin = (-122.000138888888998,37.000138888888898)
> > > Pixel Size = (0.000277777777778,-0.000277777777778)
> > > Metadata:
> > > Band_1=Band 1
> > > Image Structure Metadata:
> > > INTERLEAVE=BAND
> > > Corner Coordinates:
> > > Upper Left (-122.0001389, 37.0001389) (122d 0'0.50"W, 37d 0'0.50"N)
> > > Lower Left (-122.0001389, 34.9998611) (122d 0'0.50"W, 34d59'59.50"N)
> > > Upper Right (-118.9998611, 37.0001389) (118d59'59.50"W, 37d 0'0.50"N)
> > > Lower Right (-118.9998611, 34.9998611) (118d59'59.50"W, 34d59'59.50"N)
> > > Center (-120.5000000, 36.0000000) (120d30'0.00"W, 36d 0'0.00"N)
> > > Band 1 Block=10801x1 Type=Int16, ColorInterp=Undefined
> > > NoData Value=-32767
> > >
> > > $ gdalinfo srtm/srtm_90m_egm96_grid.tif
> > > Driver: GTiff/GeoTIFF
> > > Files: srtm/srtm_90m_egm96_grid.tif
> > > Size is 10801, 7201
> > > Coordinate System is:
> > > GEOGCS["WGS 84",
> > > DATUM["WGS_1984",
> > > SPHEROID["WGS 84",6378137,298.257223563,
> > > AUTHORITY["EPSG","7030"]],
> > > AUTHORITY["EPSG","6326"]],
> > > PRIMEM["Greenwich",0],
> > > UNIT["degree",0.0174532925199433],
> > > AUTHORITY["EPSG","4326"]]
> > > Origin = (-122.000139000000004,37.000138900000003)
> > > Pixel Size = (0.000277777777778,-0.000277777777778)
> > > Metadata:
> > > AREA_OR_POINT=Area
> > > Image Structure Metadata:
> > > INTERLEAVE=BAND
> > > Corner Coordinates:
> > > Upper Left (-122.0001390, 37.0001389) (122d 0'0.50"W, 37d 0'0.50"N)
> > > Lower Left (-122.0001390, 34.9998611) (122d 0'0.50"W, 34d59'59.50"N)
> > > Upper Right (-118.9998612, 37.0001389) (118d59'59.50"W, 37d 0'0.50"N)
> > > Lower Right (-118.9998612, 34.9998611) (118d59'59.50"W, 34d59'59.50"N)
> > > Center (-120.5000001, 36.0000000) (120d30'0.00"W, 36d 0'0.00"N)
> > > Band 1 Block=256x256 Type=Float32, ColorInterp=Gray
> > > NoData Value=-32767
> > >
> > >
> > > ----- Original Message -----
> > > From: "Even Rouault" <even.rouault at mines-paris.org>
> > > To: "Marco Nicoletti" <nicoletti at consorzio-innova.it>
> > > Cc: <gdal-dev at lists.osgeo.org>
> > > Sent: Monday, July 25, 2011 1:03 PM
> > > Subject: Re: [gdal-dev] gdalbuilvrt segmentation fault
> > >
> > >
> > > > Selon Marco Nicoletti <nicoletti at consorzio-innova.it>:
> > > >
> > > >> Dear all,
> > > >>
> > > >> I have got a problem using the GDAL tool gdalbuildvrt.
> > > >>
> > > >> I would like to join two DEMs sampled on the same grid which insist on
> > > >> the
> > > >> same
> > > >> geografical zone.
> > > >> The first DEM has got some NoDataValue holes and I would like to feel
> > > >> them
> > > >> with the values in
> > > >> the second DEM.
> > > >> I ave used also the flag to ignore the projection
> > > >> (-allow_projection_difference).
> > > >>
> > > >> DEMs have the same raster size (xSize="10801" ySize="7201"), the same
> > > >> data
> > > >> type ("Float32")
> > > >> and the same NoData Value (-3.27670000000000E+04).
> > > >>
> > > >> The GDAL tool goes in segmentation fault: any ideas?
> > > >
> > > > I'm not aware of remaining issues that could cause segmentation fault
> in
> > > > the
> > > > current version. Do you use GDAL 1.8.x or an older version ? If older,
> > > > please
> > > > upgrade and test again. If it is GDAL 1.8.0 or later, then I would need
> > > > the
> > > > datasets to reproduce.
> > > >
> > > > You could also run under a debugger or under Valgrind to see where it
> > > > crashes.
> > > >
> > > >>
> > > >> $ gdalbuildvrt -allow_projection_difference output.vrt
> > > >> ned/safod+egm96.dem
> > > >> srtm/srtm_90m_egm96_grid.tif
> > > >> 0...10...20...30...40...50...60...70...80...90...100 - done.
> > > >> Warning 6: gdalbuildvrt does not support heterogenous band
> > > >> characteristics.
> > > >> Skipping srtm/srtm_90m_egm96_grid.tif
> > > >
> > > > Hum, looking at the code, this message can happen if the datasets have
> a
> > > > different color interpreation or data type. If your both datasets have
> > > > same data
> > > > type, it must be due to the different color interpretation. Can you
> paste
> > > > the
> > > > output of gdalinfo on both datasets ? I'm wondering if that test
> shouldn't
> > > > be
> > > > relaxed : it could certainly be relaxed on color interpretation, which
> is
> > > > just
> > > > an information, and as far as different data type it could be improved
> to
> > > > select
> > > > the most appropriate datatype one or let the user define it...
> > > >
> > > > If you can build from source, you can just remove the following code in
> > > > apps/gdalbuildvrt.cpp :
> > > >
> > > > if (pasBandProperties[j].colorInterpretation !=
> > > > GDALGetRasterColorInterpretation(hRasterBand) ||
> > > > pasBandProperties[j].dataType !=
> > > > GDALGetRasterDataType(hRasterBand))
> > > > {
> > > > CPLError(CE_Warning, CPLE_NotSupported,
> > > > "gdalbuildvrt does not support
> heterogenous
> > > > band
> > > > characteristics. Skipping %s",
> > > > dsFileName);
> > > > return FALSE;
> > > > }
> > > >
> > > > Best regards,
> > > >
> > > > Even
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
More information about the gdal-dev
mailing list