2008.05.30 17:18 "[Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10", by Even Rouault

2008.06.02 14:10 "Re: [Tiff] Re: [gdal-dev] Problem with libTiff on Solaris 10", by Edward Lam

I'm anal here but I think it should really be:

nTemp = (uint32)o->tdir_offset;
_TIFFmemcpy(n, &nTemp, sizeof(uint32));

Looking at the original code snippet, the only way I can see the access be not aligned on a 4 byte boundary is if the _TIFFmalloc() (which maps to plain old malloc()) returns a pointer that is not 4-byte aligned in the first place. Or am I reading the code wrong?

Cheers,

-Edward

And I suspect that the "_TIFFmemcpy(n,&o->tdir_offset,4)" is also bogus as tdir_offset is 64 bit large too.

That should be fixed too by the same method:

nTemp = (uint32)o->tdir_offset;
_Tiffmemcpy(n, &nTemp, 4);

Those problems are probably not seen on little endian machines as the first 4 bytes contain the lowest 32 bit word, which is the one we want to put into the n pointer... I'm also wondering why there's not a test to see if it must be swabbed afterwards, as it's done for the tag, type and count fields.

Le Saturday 31 May 2008 17:30:11 Even Rouault, vous avez écrit :

Dan,

Your fix is not the right one. But I recognize that my previous suggestion could lead into error.

In fact, tdir_count field is a uint64 in libtiff 4.0.

So the correct fix is:

uint32 nTemp = (uint32)o->tdir_count;
_Tiffmemcpy(n, &nTemp, 4);

> ---------------------------------------------------------------------------

>> --------

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

> De :

Dan Greve <grevedan@hotmail.com>

> À :

Bob Friesenhahn <bfriesen@simple.dallas.tx.us>, Even Rouault <even.rouault@mines-paris.org>

> CC :

gdal-dev@lists.osgeo.org, tiff@lists.osgeo.org, Andy Cave <andy.cave@hamillroad.com>, mailing list <tiff@lists.maptools.org>

> Date :

Aujourd'hui 16:49:15

>

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.

> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev