<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>&gt;Many compilers will produce a warning if an action is performed in a <BR>&gt;way which does not assure correct alignment.<BR>
&nbsp;<BR>
I know GCC was throwing a number of warnings in the libtiff directory,<BR>maybe i'll actual pay attention to these in the next rebuild :)<BR>
&nbsp;<BR>
&gt;I've done a quick 'grep "*(int32*)" *.c ' and 'grep "*(uint32*)" *.c' on <BR>&gt;libtiff 3.8.2 sources and libtiff 4.0.0 sources, and found much more of those <BR>&gt;in the later than in the former, so it is a hint that this may be the <BR>&gt;problem.<BR>&nbsp;<BR>Bodes well that there is a greater likelihood this error would occur in libtiff 4.0.0<BR>(if this is what is included in gdal-1.5.1). I'm time crunched, so i think i'll try to<BR>to go in and replace the direct memory accesses with the TiffMemcpy like Evan<BR>suggested.<BR>
&nbsp;<BR>
&gt;Anyway, we could be sure of the reason if Dan could print the value of the n <BR>&gt;pointer when the debugger stops on the crash. And I think that 'sigbus' is <BR>&gt;more typical of alignment problems. A null pointer would have given <BR>&gt;a 'sigsegv' I think.<BR>
<BR>I'll forward the output of the n pointer from gdb, but I'm pretty sure it was not<BR>null.&nbsp; But even though the console output was "bus error", i think the debugger<BR>was segsegv, but will verify this in the morning.&nbsp; Unfortunately, due to the <BR>classification of this machine, I may not be able to provide a stack trace<BR>easily.<BR>
<BR>Thanks ya'll for the great inputs.<BR>
<BR>-- Dan Greve<BR>-- Software Engineer<BR>-- Northrop Grumman Corp.<BR><BR><BR><BR><BR>

<HR id=stopSpelling>
<BR>
&gt; Date: Fri, 30 May 2008 15:58:02 -0500<BR>&gt; From: bfriesen@simple.dallas.tx.us<BR>&gt; To: even.rouault@mines-paris.org<BR>&gt; CC: andy.cave@hamillroad.com; gdal-dev@lists.osgeo.org; grevedan@hotmail.com; tiff@lists.maptools.org; Shawn.Gong@drdc-rddc.gc.ca<BR>&gt; Subject: Re: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10<BR>&gt; <BR>&gt; On Fri, 30 May 2008, Even Rouault wrote:<BR>&gt; &gt;<BR>&gt; &gt; Related topic, do people know if there's a Valgrind option/patch that could<BR>&gt; &gt; help us to detect that ? I looked a bit but couldn't find one. I imagine<BR>&gt; &gt; that's it's "easy" for Valgrind to detect and report such unaligned memory<BR>&gt; &gt; accesses. That could enable people not having the "chance" of getting access<BR>&gt; &gt; to a SPARC platform to anticipate such problems even with i386 hardware.<BR>&gt; <BR>&gt; Many compilers will produce a warning if an action is performed in a <BR>&gt; way which does not assure correct alignment.<BR>&gt; <BR>&gt; The popular targets for valgrind do not seem to care about aligned <BR>&gt; access, or perhaps unaligned access is just a bit slower.<BR>&gt; <BR>&gt; I have access to SPARC here so if someone can formulate a simple way <BR>&gt; to re-create the problem without GDAL installed then I should be able <BR>&gt; to help debug the issue.<BR>&gt; <BR>&gt; Bob<BR>&gt; ======================================<BR>&gt; Bob Friesenhahn<BR>&gt; bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/<BR>&gt; GraphicsMagick Maintainer, http://www.GraphicsMagick.org/<BR>&gt; <BR><BR><br /><hr />Make every e-mail and IM count. <a href='http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount' target='_new'>Join the i’m Initiative from Microsoft.</a></body>
</html>