[gdal-dev] Problem with libTiff on Solaris 10

[Even Rouault]

Hi,

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.

Best regards,
Even

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

RE: [gdal-dev] Problem with libTiff on Solaris 10
De : 
"Gong, Shawn (Contractor)" <Shawn.Gong at drdc-rddc.gc.ca>
  À : 
"Dan Greve" <grevedan at hotmail.com>, gdal-dev at 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 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.