Systematic crash when opening images with GDAL (tif, png, jpeg, etc)
Mantis Issue 312, reported by smay, assigned to jmalik, created: 2011-05-24
Any binary crashes when opening images with GDAL (tif, png, jpeg, etc). Whith the debugger, I checked that it crashes in the file otbGDALImageIO.cxx, in this function : GDALDatasetWrapper::Pointer Open( std::string filename ) const
With the following line : poDataset = (GDALDataset *) GDALOpen(filename.c_str(), GA_ReadOnly);
Note : there is a warning message at the compilation step of OTB library :
CMake Warning at CMake/ImportGdal.cmake:213 (MESSAGE): CHECK_HDF4OPEN_SYMBOL test failed : your platform exhibits a problem to read HDF4 files. So the tests with HDF4 will be deactivated Call Stack (most recent call first): CMakeLists.txt:120 (INCLUDE)
GDAL is compiled with HDF4 as external lib. In the otbGDALImageIO.cxx file, it goes through this part of code : #ifndef CHECK_HDF4OPEN_SYMBOL // Get rid of the HDF4 driver when it is buggy GDALDriver* driver = GetGDALDriverManager()->GetDriverByName( "hdf4" ); if (driver) GetGDALDriverManager()->DeregisterDriver( driver ); #endif I have suppressed this part of code. Now it does not crash any more. So the DeregisterDriver function causes a problem conducting to the crash of GdalOpen function.
Any idea ?
External libs : GDAL 1.6.2 + HDF 4.2r5 + TIFF 3.8.2 + GEOTIFF 1.2.3 + CURL 7.13
Problem reproduced with GDAL 1.8.0 + HDF 4.2r5 + TIFF 3.8.2 + GEOTIFF 1.2.3 + CURL 7.13
1306239342 - julienmSee "incompatibility" section in http://trac.osgeo.org/gdal/wiki/HDF See also the discussion in the related bug.
Do you enter in one of the cases (build with both HDF4 and NetCDF support, or build with non-standard libz) ?
1306239969 - julienmIf the CHECK_HDF4OPEN_SYMBOL is false (so you enter in the part where it deregister the driver), then it means that this program : http://hg.orfeo-toolbox.org/OTB/file/893ea1e8575b/CMake/TestHDF4Open.cxx failed to run.
Can you test it with your own GDAL, outside any OTB related stuff to confirm that there is a problem (in this test, all available drivers are used : does it go to the end and quit on error, or does it fail before that) ?
The status was that there was a problem when accessing a HDF4 dataset in some cases, depending on the flavour of the libhdf4 package (on Debian-like system, gdal must be compiled with the libhdf4-alt-dev package, and not libhdf4g-dev).
But the problem was only when calling RasterIO, not at GDALOpen