2018.04.24 20:18 "Re: [Tiff] libTiff Bug", by SM
Sorry forgot provide the code
#include <tiffio.h>
int main()
{
TIFF *tif=TIFFOpen("Test_001.tif", "r");
uint64 width;
uint64 height;
TIFFGetField(tif, TIFFTAG_IMAGEWIDTH, &width);
TIFFGetField(tif, TIFFTAG_IMAGELENGTH, &height);
uint64 npixels=width*height;
uint32* raster=(uint32 *) _TIFFmalloc(npixels *sizeof(uint32));
TIFFReadRGBAImage(tif, width, height, raster, 0);
}
This program crashes.
Thanks,
-SM
On Tue, Apr 24, 2018 at 4:14 PM, SM <skypemesm@gmail.com> wrote:
> I understand your concerns with the code. I was only writing a dummy > example to demonstrate the issue.
>
> See this:
>
> (gdb) r
> Starting program: a.out
>
> Breakpoint 1, main () at main.c:4
> 4 TIFF *tif=TIFFOpen("Test_001.tif", "r");
> (gdb) n
> 7 TIFFGetField(tif, TIFFTAG_IMAGEWIDTH, &width);
> (gdb)
> 8 TIFFGetField(tif, TIFFTAG_IMAGELENGTH, &height);
> (gdb)
> 9 uint64 npixels=width*height;
> (gdb)
> 10 uint32* raster=(uint32 *) _TIFFmalloc(npixels *sizeof(uint32));
> (gdb)
> 11 if (raster != NULL)
> (gdb)
> 12 TIFFReadRGBAImage(tif, width, height, raster, 0);
> (gdb)
>
> Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff7b8b3e2 in putRGBcontig8bittile (img=img@entry=0x7fffffffdfb0,
> cp=0x7ff885718014, cp@entry=0x7ff88a6d4010, x=x@entry=0, y=y@entry=50175, > w=w@entry=512, h=268, h@entry=512, fromskew=0,
> toskew=-86528,
> pp=0x7ffff7eeb210 "\350\347\355\350\347\355\350\
> 347\355\350\347\355\350\347\355\350\347\355\350\347\355\
> 350\347\355\345\344\352\346\345\353\347\346\354\350\347\
> 355\350\347\355\347\346\354\346\345\353\345\344\352\351\
> 346\355\351\346\355\351\346\355\351\346\355\351\346\355\
> 351\346\355\351\346\355\351\346\355\350\345\354\350\345\
> 354\350\345\354\350\345\354\350\345\354\350\345\354\350\
> 345\354\350\345\354\346\345\353\347\346\354\350\347\355\
> 351\350\356\351\350\356\350\347\355\347\346\354\346\345\
> 353\345\344\352\346\345\353\347\346\354\347\346\354\346\
> 345\353\346\345\353\347\346\354\350\347\355\346\345\353\
> 346\345\353\347\346\354\347\346\354\347\346\354\347\346\
> 354\346\345\353\346\345\353\350\347\355\350\347\355\350\
> 347\355\350\347\355\347\346\354\347\346\354\347\346\354\
> 347\346\354\347\346\354\347\346\354\347", <incomplete sequence \346>...)
> at tif_getimage.c:1376
> 1376 UNROLL8(w, NOP,
> (gdb) bt
> #0 0x00007ffff7b8b3e2 in putRGBcontig8bittile (img=img@entry=0x7fffffffdfb0,
> cp=0x7ff885718014, cp@entry=0x7ff88a6d4010, x=x@entry=0, y=y@entry=50175,
> w=w@entry=512, h=268, h@entry=512, fromskew=0,
> toskew=-86528,
> pp=0x7ffff7eeb210 "\350\347\355\350\347\355\350\
> 347\355\350\347\355\350\347\355\350\347\355\350\347\355\
> 350\347\355\345\344\352\346\345\353\347\346\354\350\347\
> 355\350\347\355\347\346\354\346\345\353\345\344\352\351\
> 346\355\351\346\355\351\346\355\351\346\355\351\346\355\
> 351\346\355\351\346\355\351\346\355\350\345\354\350\345\
> 354\350\345\354\350\345\354\350\345\354\350\345\354\350\
> 345\354\350\345\354\346\345\353\347\346\354\350\347\355\
> 351\350\356\351\350\356\350\347\355\347\346\354\346\345\
> 353\345\344\352\346\345\353\347\346\354\347\346\354\346\
> 345\353\346\345\353\347\346\354\350\347\355\346\345\353\
> 346\345\353\347\346\354\347\346\354\347\346\354\347\346\
> 354\346\345\353\346\345\353\350\347\355\350\347\355\350\
> 347\355\350\347\355\347\346\354\347\346\354\347\346\354\
> 347\346\354\347\346\354\347\346\354\347", <incomplete sequence \346>...)
> at tif_getimage.c:1376
> #1 0x00007ffff7b90643 in gtTileContig (img=0x7fffffffdfb0,
> raster=0x7ff885728010, w=86016, h=89600) at tif_getimage.c:673
> #2 0x00007ffff7b92dfd in TIFFReadRGBAImageOriented (tif=<optimized out>,
> rwidth=86016, rheight=<optimized out>, raster=0x7ff885728010,
> orientation=4, stop=0) at tif_getimage.c:514
> #3 0x0000000000400807 in main () at main.c:12
> (gdb)
>
> Thanks,
> SM
>
> On Tue, Apr 24, 2018 at 3:04 PM, Bob Friesenhahn <
> bfriesen@simple.dallas.tx.us> wrote:
>
>> On Tue, 24 Apr 2018, Even Rouault wrote:
>>
>>>
>>> That's still not correct. The widening to uint64 occurs after the
>>> multiplication which is done
>>> on uint32. So you need to explicitly cast to uint64 one of width or
>>> height too
>>>
>>> uint64 npixels = (uint64)width * height;
>>>
>>
>> It is also necessary to check the pointer returned by _TIFFmalloc() to >> assure that it is not NULL. Address space and memory is finite.
Bob
--
Bob Friesenhahn
>> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/u
>> sers/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
>
>