2008.05.30 17:18 "[Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10", by Even Rouault

2008.05.30 18:40 "Re: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10", by Andy Cave

Hi Even,

Yes IIRC from when I worked/coded on them SPARCS need to do aligned accesses, or you get a trap.

But without knowing the code, also, o could be a null pointer (is it asserted as not being null on entry to the function or where it's set/calculated/extracted?).

Regards,

Andy.

----- Original Message -----

Cc: "Dan Greve" <grevedan@hotmail.com>; "TIFF mailing list" <tiff@lists.maptools.org>; "Gong,Shawn (Contractor)"

<Shawn.Gong@drdc-rddc.gc.ca>

Sent: Friday, May 30, 2008 7:18 PM Subject: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10

Hum, I'm not a specialist of SPARC at all, but doesn't this architecture require proper memory alignment accesses?

I say that because the crash on " *(uint32*)n=(uint32)o->tdir_count " could be easily explained if the memory address pointed by 'n' is not aligned on a 4 byte address....

In the next few lines of the code extract Dan Greve has quoted, I see "_TIFFmemcpy(n,&o->tdir_offset,4)" which is a safer way of dealing with this alignment problems...

It looks like a libtiff problem, so I add the libtiff mailing list in CC too.

-------------------------------------------------------------------------------------

RE: [gdal-dev] Problem with libTiff on Solaris 10
De :
"Gong, Shawn (Contractor)" <Shawn.Gong@drdc-rddc.gc.ca>
  À :
"Dan Greve" <grevedan@hotmail.com>, gdal-dev@lists.osgeo.org
  Date :
Aujourd'hui 18:54:44

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@lists.osgeo.org [mailto:gdal-dev-bounces@lists.osgeo.org] On Behalf Of Dan Greve Sent: Friday, May 30, 2008 11:51 AM

To: gdal-dev@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_f