[gdal-dev] Problem with libTiff on Solaris 10

[Dan Greve]

Shawn,

Hopefully we can solve both our problems.  It's hard for the developers to run their tests unless they have similiar hardware.  If one of the developers want, i may be able to produce a SPARC system to run tests through.

-- Dan Greve
-- Software Engineer
-- Northrop Grumman Corp.

> Subject: RE: [gdal-dev] Problem with libTiff on Solaris 10
> Date: Fri, 30 May 2008 12:54:44 -0400
> From: Shawn.Gong at drdc-rddc.gc.ca
> To: grevedan at hotmail.com; gdal-dev at lists.osgeo.org
> 
> Dan and list,
> 
> This error looks very similar to what I have experienced on our Sun machine, trying to build and run gdal 1.5.1.
> Our Sun system is SPARC Solaris 9 64-bit.
> 
> Error message when Python codes call "gtiff_driver.CreateCopy( fname, vrtds, ...)"
> ERROR 1: /home/sgong/../working_dir/test2.tif:No space to read TIFF directory
> ERROR 1: TIFFReadDirectory:Failed to read directory at offset 8 Bus error (core dumped)
> 
> 
> thanks, 
> Shawn 
> 
> ________________________________________
> From: gdal-dev-bounces at lists.osgeo.org [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Dan Greve
> Sent: Friday, May 30, 2008 11:51 AM
> To: gdal-dev at lists.osgeo.org
> Subject: [gdal-dev] Problem with libTiff on Solaris 10
> 
> Greetings,
> 
> I am using the latest stable build, gdal-1.5.1 on a SPARC Solaris 10 64-bit system.  It is configured with the default drivers, but is using --with-jpeg=internal --with-libtiff=internal --with-geotiff=internal.  Using the 32-bit compiler options and libraries, I can successfully build libgdal.so and the utility programs.  However, when trying to do a gdal_translate from one simple uncompressed 3-band geotiff into another simple uncompressed 3-band geotiff, I get a "bus error" segfault.  Also, if the output tiff already exists I get two errors. "No space to read tiff directory" and "TiffReadDirectory: failed to read directory at offset 8". A quick google revealed two similiar errors, here and here. Diving into the debugger, the problem seems to lie in the tif_dirwrite.c, starting with line 755.  I believe it's due to _TIFFmalloc not allocating memory properly. The crash actual occurs on line 781, *(uint32*)n=(uint32)o->tdir_count;  
> 
> o->tdir_count is valid, but setting n to any value causes a segfault, as though TIFFmalloc did not allocate the whole requested 186 bytes. Any ideas?
> 
> <snip file=tif_dirwrite.c>
>     dirmem=_TIFFmalloc(dirsize);
>     if (dirmem==NULL)
>     {
>         TIFFErrorExt(tif->tif_clientdata,module,"Out of memory");
>         goto bad;
>     }
>     if (!(tif->tif_flags&TIFF_BIGTIFF))
>     {
>         uint8* n;
>         TIFFDirEntry* o;
>         n=dirmem;
>         *(uint16*)n=ndir;
>         if (tif->tif_flags&TIFF_SWAB)
>             TIFFSwabShort((uint16*)n);
>         n+=2;
>         o=dir;
>         for (m=0; m<ndir; m++)
>         {
>             *(uint16*)n=o->tdir_tag;
>             if (tif->tif_flags&TIFF_SWAB)
>                 TIFFSwabShort((uint16*)n);
>             n+=2;
>             *(uint16*)n=o->tdir_type;
>             if (tif->tif_flags&TIFF_SWAB)
>                 TIFFSwabShort((uint16*)n);
>             n+=2;
>             *(uint32*)n=(uint32)o->tdir_count;
>             if (tif->tif_flags&TIFF_SWAB)
>                 TIFFSwabLong((uint32*)n);
>             n+=4;
>             _TIFFmemcpy(n,&o->tdir_offset,4);
>             n+=4;
>             o++;
>         }
>         *(uint32*)n = (uint32)tif->tif_nextdiroff;
>     }
> </snip>
> 
> -- Dan Greve
> -- Software Engineer
> -- Northrop Grumman Corp.
> 
> 

_________________________________________________________________
Keep your kids safer online with Windows Live Family Safety.
http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_Refresh_family_safety_052008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20080530/9f322937/attachment.html