[Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10

[Dan Greve]

Sure enough, the pointer n is not null, and throws a sigsegv fault. Aftern changing from
 
*(uint32*)n=(uint32)o->tdir_count;            TO
 
_TIFFmemcpy(n, &o->tdir_count, 4)
 
The execution passes this point, but where as *(uint32*)n should be 1, it is 0. This causes errors later in the GDALOpen call on the tiff dataset, which fails with error "TiffFetchNormalTag:incorrect count for "SamplesPerPixel". 
debugging continues....
 
-- Dan Greve
-- Software Engineering
-- Northrop Grumman Corp.


From: grevedan at hotmail.comTo: bfriesen at simple.dallas.tx.us; even.rouault at mines-paris.orgSubject: RE: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10Date: Fri, 30 May 2008 19:53:49 -0400CC: gdal-dev at lists.osgeo.org; TIFF at lists.osgeo.org; andy.cave at hamillroad.com; tiff at lists.maptools.org


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

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

Make every e-mail and IM count. Join the i’m Initiative from Microsoft. 
_________________________________________________________________
Keep your kids safer online with Windows Live Family Safety.
http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_Refresh_family_safety_052008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20080531/4d9a3cae/attachment.html