[Gdal-dev] GeoTIFF file which crashes GDAL?

[Ben Discoe]

Hi Frank and Vincent,

Thanks for spending the time looking into the problems with the file...
but i think the question i'm asking is... is it possible to GDAL to just
return an error instead of crashing?  I'm not asking for GDAL to read
messy/problematic files, that is understandably not worth effort, just
if it could not crash..

Thanks,
Ben

> -----Original Message-----
> From: gdal-dev-admin at remotesensing.org 
> [mailto:gdal-dev-admin at remotesensing.org] On Behalf Of Frank Warmerdam
> Sent: Friday, July 18, 2003 10:12 AM
> To: gdal-dev at remotesensing.org
> Subject: Re: [Gdal-dev] GeoTIFF file which crashes GDAL?
> 
> 
> Ben Discoe wrote:
> 
> > I have a GeoTIFF which was output from the MultiSpec remote-sensing
> > analysis program (http://www.ece.purdue.edu/~biehl/MultiSpec/).  It
> > crashes in GDAL (on Windows) when i try to load it.  Tested it with
> > gdalinfo, and that crashes too.
> > 
> > I've uploaded it here: http://vterrain.org/Temp/problem.zip
> > 
> > It loads fine in PhotoShop, so there must be something about the
> > non-picture TIF elements in it.  It would be fine if GDAL 
> gave an error
> > and refused to load it, but a crash is not good..
> 
> Ben,
> 
> I checked the image, and run into similar problems.  The 
> tiffdump reports:
> 
> problem.tif:
> Magic: 0x4949 <little-endian> Version: 0x2a
> Directory 0: offset 8 (0x8) next 524296 (0x80008)
> SubFileType (254) LONG (4) 1<0>
> ImageWidth (256) LONG (4) 1<1702>
> ImageLength (257) LONG (4) 1<1405>
> BitsPerSample (258) SHORT (3) 3<8 8 8>
> Compression (259) SHORT (3) 1<1>
> Photometric (262) SHORT (3) 1<2>
> StripOffsets (273) LONG (4) 1<366>
> SamplesPerPixel (277) SHORT (3) 1<3>
> RowsPerStrip (278) LONG (4) 1<1405>
> StripByteCounts (279) LONG (4) 1<2391310>
> XResolution (282) RATIONAL (5) 1<1>
> YResolution (283) RATIONAL (5) 1<1>
> PlanarConfig (284) SHORT (3) 1<1>
> ResolutionUnit (296) SHORT (3) 1<1>
> SampleFormat (339) SHORT (3) 3<1 1 1>
> 33550 (0x830e) DOUBLE (12) 3<28.5 28.5 0>
> 33922 (0x8482) DOUBLE (12) 6<0 0 0 397931 847177 0>
> 34735 (0x87af) SHORT (3) 20<1 1 0 4 1024 0 1 1 1025 0 1 1 
> 2052 0 1 9001 3072 0 1 
> 32617>
> 
> Directory 1: offset 524296 (0x80008) next 490688554 (0x1d3f502a)
> 5401 (0x1519) 4447 (0x115f) 236019477<>
> 3601 (0xe11) 6506 (0x196a) 604793365<>
> ...
> 
> So the main problem seems to be that the second directory starts
> at 524296 which is in the middle of the first image (2391310 bytes
> starting at 366).  Given the mess that is the second directory I
> would guess the image was written over the directory.  So GDAL
> and some of the libtiff tools crash trying to read the second
> directory.
> 
> I tried hacking up version of GDAL that would just read the first
> directory, and it still resulted in corruption part way down 
> the image.
> I don't really know why, but having spent an hour or two on this image
> I am ready to throw in the towel.
> 
> Later,
> 
> -- 
> ---------------------------------------+----------------------
> ----------------
> I set the clouds in motion - turn up   | Frank Warmerdam, 
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial 
> Programmer for Rent
> 
> 
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at remotesensing.org
> http://remotesensing.org/mailman/listinfo/gdal-dev
>