AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
May 2008

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2008.05.30 17:18 "Re: [gdal-dev] Problem with libTiff on Solaris 10", by Even Rouault
2008.05.30 18:40 "Re: [gdal-dev] Problem with libTiff on Solaris 10", by Andy Cave
2008.05.30 19:19 "Re: [gdal-dev] Problem with libTiff on Solaris 10", by Even Rouault
2008.05.30 20:58 "Re: [gdal-dev] Problem with libTiff on Solaris 10", by Bob Friesenhahn
2008.05.31 15:30 "Re: [gdal-dev] Problem with libTiff on Solaris 10", by Even Rouault
2008.05.31 15:45 "Re: [gdal-dev] Problem with libTiff on Solaris 10", by Even Rouault
2008.06.02 14:10 "Re: [gdal-dev] Problem with libTiff on Solaris 10", by Edward Lam

2008.05.30 17:18 "Re: [gdal-dev] Problem with libTiff on Solaris 10", by 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@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_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.