Segfault when reading a .dem.hdr file
Mantis Issue 150, reported by echristophe, assigned to jmalik, created: 2010-03-26
OTB (otbViewerManager for example) segfault when reading a file with a .dem.hdr extension. The .dem part is incorrectly redirected to ossim which segfault.
(gdb) bt #0 0x00007ffff6918a56 in ossimDemProfile::getNumberOfElevations (this=0x0) at /home/christop/OTB/trunk/OTB/Utilities/otbossim/src/ossim/support_data/ossimDemProfile.cpp:71 #1 (closed) 0x00007ffff6942536 in ossimDemGrid::fillGeographic (this=0x913680, dem=..., incrementalRead=false) at /home/christop/OTB/trunk/OTB/Utilities/otbossim/src/ossim/support_data/ossimDemGrid.cpp:105 #2 (closed) 0x00007ffff6942273 in ossimDemGrid::read (this=0x913680, dem=..., incrementalRead=false) at /home/christop/OTB/trunk/OTB/Utilities/otbossim/src/ossim/support_data/ossimDemGrid.cpp:43 #3 (closed) 0x00007ffff6af63e3 in ossimUsgsDemTileSource::open (this=0x9112a0) at /home/christop/OTB/trunk/OTB/Utilities/otbossim/src/ossim/imaging/ossimUsgsDemTileSource.cpp:253 #4 (closed) 0x00007ffff6b26e51 in ossimImageHandler::open (this=0x9112a0, imageFile=...) at /home/christop/OTB/trunk/OTB/Utilities/otbossim/src/ossim/imaging/ossimImageHandler.cpp:923 #5 (closed) 0x00007ffff6bcfc08 in ossimImageHandlerFactory::openFromExtension (this=0x8ebf20, fileName=...) at /home/christop/OTB/trunk/OTB/Utilities/otbossim/src/ossim/imaging/ossimImageHandlerFactory.cpp:694 #6 (closed) 0x00007ffff6bcd481 in ossimImageHandlerFactory::open (this=0x8ebf20, fileName=...) at /home/christop/OTB/trunk/OTB/Utilities/otbossim/src/ossim/imaging/ossimImageHandlerFactory.cpp:89 #7 (closed) 0x00007ffff6b1dddc in ossimImageHandlerRegistry::open (this=0x7ffff73123c0, fileName=...) at /home/christop/OTB/trunk/OTB/Utilities/otbossim/src/ossim/imaging/ossimImageHandlerRegistry.cpp:161 #8 (closed) 0x00000000004f7031 in otb::ImageFileReader<otb::VectorImage<double, 2u> >::GenerateOutputInformation (this=0x8dbc80) at /home/christop/OTB/trunk/OTB/Code/IO/otbImageFileReader.txx:374 #9 (closed) 0x00000000004ed186 in otb::ImageViewerManagerModel::OpenImage (this=0x8c82c0, filename=...) at /home/christop/OTB/trunk/OTB-Applications/ViewerManager/Model/otbImageViewerManagerModel.cxx:72 #10 (closed) 0x00000000004eb626 in otb::ImageViewerManagerController::OpenInputImage (this=0x8c8220, filename=0x7fffffffe39e "20080510.dem.hdr") at /home/christop/OTB/trunk/OTB-Applications/ViewerManager/Controller/otbImageViewerManagerController.cxx:51 #11 (closed) 0x00000000004b5d24 in otb::ImageViewerManagerViewGUI::Initialize (this=0x8c85a0, cfname=0x7fffffffe39e "20080510.dem.hdr") at /home/christop/OTB/trunk/OTB-Applications/ViewerManager/View/otbImageViewerManagerViewGUI.cxx:116 #12 (closed) 0x00000000004b5aca in otb::ImageViewerManagerViewGUI::OpenImage (this=0x8c85a0, inputFileName=0x7fffffffe39e "20080510.dem.hdr") at /home/christop/OTB/trunk/OTB-Applications/ViewerManager/View/otbImageViewerManagerViewGUI.cxx:81 #13 (closed) 0x00000000004b10c0 in main (argc=2, argv=0x7fffffffe088) at /home/christop/OTB/trunk/OTB-Applications/ViewerManager/otbImageViewerManager.cxx:73
1275320273 - julienmYou mean a .dem file which have been renamed to .dem.hdr ? Or is this a common use case to have .dem.hdr files ?
What is the expected behavior ? Thanks for the details.
1275321627 - christopI have an application (Gamma) producing raw files called something.dem To read raw file with OTB, one easy way is to use the envi format:
- xyz contains the data
- xyz.hdr the header that gives the organization of the data
in my case xyz == something.dem => the header is named something.dem.hdr
The ideal behavior would be to open the file as an envi file with gdal. At least, it should not segfault.
1275323481 - julienm- from OTB-Data, i take Input/poupees & Input/poupees.hdr
- rename them to poupees.dem & poupees.dem.hdr
- open poupees.dem or poupees.dem.hdr in monteverdi & otbimageViewerManager
it does not crash and the input data are read correctly
is the bug gone ?
1275357212 - christopThe diagnostic might be wrong, I also find another example where it does no