2008.05.30 19:19 "Re: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10", by Even Rouault
Yes, it could be an issue about a NULL pointer of course, but libtiff 4.0.0 alpha/beta works well on i386, x86_64, PPC etc... (those are the platforms tested by the GDAL buildbot)
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.
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.
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.
Le Friday 30 May 2008 20:40:43 Andy Cave, vous avez écrit :
Yes IIRC from when I worked/coded on them SPARCS need to do aligned accesses, or you get a trap.
But without knowing the code, also, o could be a null pointer (is it asserted as not being null on entry to the function or where it's set/calculated/extracted?).
Cc: "Dan Greve" <grevedan@hotmail.com>; "TIFF mailing list" <tiff@lists.maptools.org>; "Gong,Shawn (Contractor)"
<Shawn.Gong@drdc-rddc.gc.ca>
Sent: Friday, May 30, 2008 7:18 PM Subject: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10
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.
> ---------------------------------------------------------------------------
>----------
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
> sim