<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
in my case o is not a null pointer, as o->tdir_count is 1.<br><br>-- Dan Greve<br>-- Software Engineer<br>-- Northrop Grumman Corp.<br><br>> From: andy.cave@hamillroad.com<br>> To: even.rouault@mines-paris.org; gdal-dev@lists.osgeo.org<br>> CC: grevedan@hotmail.com; tiff@lists.maptools.org; Shawn.Gong@drdc-rddc.gc.ca<br>> Subject: Re: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10<br>> Date: Fri, 30 May 2008 20:40:43 +0200<br>> <br>> Hi Even,<br>> <br>> Yes IIRC from when I worked/coded on them SPARCS need to do aligned <br>> accesses, or you get a trap.<br>> <br>> But without knowing the code, also, o could be a null pointer (is it <br>> asserted as not being null on entry to the function or where it's <br>> set/calculated/extracted?).<br>> <br>> Regards,<br>> <br>> Andy.<br>> <br>> ----- Original Message ----- <br>> From: "Even Rouault" <even.rouault@mines-paris.org><br>> To: <gdal-dev@lists.osgeo.org><br>> Cc: "Dan Greve" <grevedan@hotmail.com>; "TIFF mailing list" <br>> <tiff@lists.maptools.org>; "Gong,Shawn (Contractor)" <br>> <Shawn.Gong@drdc-rddc.gc.ca><br>> Sent: Friday, May 30, 2008 7:18 PM<br>> Subject: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10<br>> <br>> <br>> Hi,<br>> <br>> Hum, I'm not a specialist of SPARC at all, but doesn't this architecture<br>> require proper memory alignment accesses ?<br>> <br>> I say that because the crash on " *(uint32*)n=(uint32)o->tdir_count " could <br>> be<br>> easily explained if the memory address pointed by 'n' is not aligned on a 4<br>> byte address....<br>> In the next few lines of the code extract Dan Greve has quoted, I<br>> see "_TIFFmemcpy(n,&o->tdir_offset,4)" which is a safer way of dealing with<br>> this alignment problems...<br>> <br>> It looks like a libtiff problem, so I add the libtiff mailing list in CC <br>> too.<br>> <br>> Best regards,<br>> Even<br>> <br>> -------------------------------------------------------------------------------------<br>> <br>> RE: [gdal-dev] Problem with libTiff on Solaris 10<br>> De :<br>> "Gong, Shawn (Contractor)" <Shawn.Gong@drdc-rddc.gc.ca><br>> À :<br>> "Dan Greve" <grevedan@hotmail.com>, gdal-dev@lists.osgeo.org<br>> Date :<br>> Aujourd'hui 18:54:44<br>> <br>> Dan and list,<br>> <br>> This error looks very similar to what I have experienced on our Sun machine,<br>> trying to build and run gdal 1.5.1.<br>> Our Sun system is SPARC Solaris 9 64-bit.<br>> <br>> Error message when Python codes call "gtiff_driver.CreateCopy( fname,<br>> vrtds, ...)"<br>> ERROR 1: /home/sgong/../working_dir/test2.tif:No space to read TIFF <br>> directory<br>> ERROR 1: TIFFReadDirectory:Failed to read directory at offset 8 Bus error<br>> (core dumped)<br>> <br>> <br>> thanks,<br>> Shawn<br>> <br>> ________________________________________<br>> From: gdal-dev-bounces@lists.osgeo.org<br>> [mailto:gdal-dev-bounces@lists.osgeo.org] On Behalf Of Dan Greve<br>> Sent: Friday, May 30, 2008 11:51 AM<br>> To: gdal-dev@lists.osgeo.org<br>> Subject: [gdal-dev] Problem with libTiff on Solaris 10<br>> <br>> Greetings,<br>> <br>> I am using the latest stable build, gdal-1.5.1 on a SPARC Solaris 10 64-bit<br>> system. It is configured with the default drivers, but is<br>> using --with-jpeg=internal --with-libtiff=internal --with-geotiff=internal.<br>> Using the 32-bit compiler options and libraries, I can successfully build<br>> libgdal.so and the utility programs. However, when trying to do a<br>> gdal_translate from one simple uncompressed 3-band geotiff into another<br>> simple uncompressed 3-band geotiff, I get a "bus error" segfault. Also, if<br>> the output tiff already exists I get two errors. "No space to read tiff<br>> directory" and "TiffReadDirectory: failed to read directory at offset 8". A<br>> quick google revealed two similiar errors, here and here. Diving into the<br>> debugger, the problem seems to lie in the tif_dirwrite.c, starting with line<br>> 755. I believe it's due to _TIFFmalloc not allocating memory properly. The<br>> crash actual occurs on line 781, *(uint32*)n=(uint32)o->tdir_count;<br>> <br>> o->tdir_count is valid, but setting n to any value causes a segfault, as<br>> though TIFFmalloc did not allocate the whole requested 186 bytes. Any ideas?<br>> <br>> <snip file=tif_dirwrite.c><br>> dirmem=_TIFFmalloc(dirsize);<br>> if (dirmem==NULL)<br>> {<br>> TIFFErrorExt(tif->tif_clientdata,module,"Out of memory");<br>> goto bad;<br>> }<br>> if (!(tif->tif_flags&TIFF_BIGTIFF))<br>> {<br>> uint8* n;<br>> TIFFDirEntry* o;<br>> n=dirmem;<br>> *(uint16*)n=ndir;<br>> if (tif->tif_flags&TIFF_SWAB)<br>> TIFFSwabShort((uint16*)n);<br>> n+=2;<br>> o=dir;<br>> for (m=0; m<ndir; m++)<br>> {<br>> *(uint16*)n=o->tdir_tag;<br>> if (tif->tif_flags&TIFF_SWAB)<br>> TIFFSwabShort((uint16*)n);<br>> n+=2;<br>> *(uint16*)n=o->tdir_type;<br>> if (tif->tif_flags&TIFF_SWAB)<br>> TIFFSwabShort((uint16*)n);<br>> n+=2;<br>> *(uint32*)n=(uint32)o->tdir_count;<br>> if (tif->tif_flags&TIFF_SWAB)<br>> TIFFSwabLong((uint32*)n);<br>> n+=4;<br>> _TIFFmemcpy(n,&o->tdir_offset,4);<br>> n+=4;<br>> o++;<br>> }<br>> *(uint32*)n = (uint32)tif->tif_nextdiroff;<br>> }<br>> </snip><br>> <br>> -- Dan Greve<br>> -- Software Engineer<br>> -- Northrop Grumman Corp.<br>> <br>> _______________________________________________<br>> Tiff mailing list: Tiff@lists.maptools.org<br>> http://lists.maptools.org/mailman/listinfo/tiff<br>> http://www.remotesensing.org/libtiff/ <br>> <br>> <br><br /><hr />E-mail for the greater good. <a href='http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ GreaterGood' target='_new'>Join the i’m Initiative from Microsoft.</a></body>
</html>