Received: from mailgate002.isp.belgacom.be (mailgate002.isp.belgacom.be [195.238.6.87])
	by maildelivery020.isp.belgacom.be (Postfix) with ESMTP id 442C17AC04F
	for <joris.at.lebbeke@skynet.be>; Fri, 30 May 2008 21:17:39 +0200 (CEST)
Authentication-Results: in.mx.skynet.be; dkim=neutral (message not signed) header.i=none
Received: from r153.dmsolutions.ca (HELO duke.maptools.org) ([209.217.116.153])
  by in.mx.skynet.be with ESMTP; 30 May 2008 21:17:38 +0200
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m4UIevlD017935;
	Fri, 30 May 2008 14:42:12 -0400
Received: from dns2.namehog.net (dns2.namehog.net [213.52.234.203])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m4UIesEx017932
	for <tiff@lists.maptools.org>; Fri, 30 May 2008 14:40:55 -0400
Received: from [77.11.117.47] (port=1396 helo=EKAT)
	by dns2.namehog.net with esmtpa (Exim 4.68)
	(envelope-from <andy.cave@hamillroad.com>)
	id 1K29XI-0003FO-Uy; Fri, 30 May 2008 19:41:09 +0100
Message-ID: <00f801c8c284$ac5c9780$2ab2a8c0@EKAT>
From: "Andy Cave" <andy.cave@hamillroad.com>
To: "Even Rouault" <even.rouault@mines-paris.org>, <gdal-dev@lists.osgeo.org>
References: <BAY118-W48661A64DCC8F8DD5F1FD1C7BE0@phx.gbl><DF1471B5C308B346BF5A2AEA00C5615E1200A6@ottawaex02.Ottawa.drdc-rddc.gc.ca>
	<200805301918.32519.even.rouault@mines-paris.org>
Subject: Re: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10
Date: Fri, 30 May 2008 20:40:43 +0200
Organization: Hamillroad Software
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - dns2.namehog.net
X-AntiAbuse: Original Domain - lists.maptools.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hamillroad.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: Dan Greve <grevedan@hotmail.com>,
        TIFF mailing list <tiff@lists.maptools.org>,
        "Gong,
	Shawn \(Contractor\)" <Shawn.Gong@drdc-rddc.gc.ca>
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Andy Cave <andy.cave@hamillroad.com>
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
Content-Transfer-Encoding: quoted-printable
X-UIDL: 000000000023ceae.00002d33
X-MSP-STORE: Fri, 30 May 2008 21:17:39 +0200
Status:   

Hi Even,

Yes IIRC from when I worked/coded on them SPARCS need to do aligned=20
accesses, or you get a trap.

But without knowing the code, also, o could be a null pointer (is it=20
asserted as not being null on entry to the function or where it's=20
set/calculated/extracted?).

Regards,

Andy.

----- Original Message -----=20
From: "Even Rouault" <even.rouault@mines-paris.org>
To: <gdal-dev@lists.osgeo.org>
Cc: "Dan Greve" <grevedan@hotmail.com>; "TIFF mailing list"=20
<tiff@lists.maptools.org>; "Gong,Shawn (Contractor)"=20
<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


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=3D(uint32)o->tdir_count " c=
ould=20
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 wi=
th
this alignment problems...

It looks like a libtiff problem, so I add the libtiff mailing list in CC=20
too.

Best regards,
Even

-------------------------------------------------------------------------=
------------

RE: [gdal-dev] Problem with libTiff on Solaris 10
De :
"Gong, Shawn (Contractor)" <Shawn.Gong@drdc-rddc.gc.ca>
  =C0 :
"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 machi=
ne,
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=20
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-b=
it
system. It is configured with the default drivers, but is
using --with-jpeg=3Dinternal --with-libtiff=3Dinternal --with-geotiff=3Di=
nternal.
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, i=
f
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 l=
ine
755. I believe it's due to _TIFFmalloc not allocating memory properly. Th=
e
crash actual occurs on line 781, *(uint32*)n=3D(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 ide=
as?

<snip file=3Dtif_dirwrite.c>
dirmem=3D_TIFFmalloc(dirsize);
if (dirmem=3D=3DNULL)
{
TIFFErrorExt(tif->tif_clientdata,module,"Out of memory");
goto bad;
}
if (!(tif->tif_flags&TIFF_BIGTIFF))
{
uint8* n;
TIFFDirEntry* o;
n=3Ddirmem;
*(uint16*)n=3Dndir;
if (tif->tif_flags&TIFF_SWAB)
TIFFSwabShort((uint16*)n);
n+=3D2;
o=3Ddir;
for (m=3D0; m<ndir; m++)
{
*(uint16*)n=3Do->tdir_tag;
if (tif->tif_flags&TIFF_SWAB)
TIFFSwabShort((uint16*)n);
n+=3D2;
*(uint16*)n=3Do->tdir_type;
if (tif->tif_flags&TIFF_SWAB)
TIFFSwabShort((uint16*)n);
n+=3D2;
*(uint32*)n=3D(uint32)o->tdir_count;
if (tif->tif_flags&TIFF_SWAB)
TIFFSwabLong((uint32*)n);
n+=3D4;
_TIFFmemcpy(n,&o->tdir_offset,4);
n+=3D4;
o++;
}
*(uint32*)n =3D (uint32)tif->tif_nextdiroff;
}
</snip>

-- Dan Greve
-- Software Engineer
-- Northrop Grumman Corp.

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/=20


_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
