2014.06.04 14:15 "Re: [Tiff] Inconsistencies in tiff library tool operation", by Bob Friesenhahn

I have done some more investigation/work on this with GraphicsMagick using only the TIFF library. Some fixes were necessary in GraphicsMagick to more properly respond to error return codes from libtiff and avoid some use of uninitialized tag values.

With the fixes in place, these are the few files (and the causing area) which still caused problems when using GraphicsMagick:

551adc8ce6c3c9cc59040903b0428f47.tif inflateReset2 7324fcaff3aad96f27899da51c1bb5d9.tif inflateReset2 m1-68bc8a1966db7a1da2d3b5946c00d1af.tif Fax4Decode m1-96292a1bd64fec83bb6cdd2480a755b6.tif inflateReset2 m3-d0f86ab189cbe900ec389ca6d7464713.tif out of memory!

I believe that the first two 'inflateReset2' glitches may be due to zlib and could be masked by adding appropriate suppressions for valgrind. The last one (m1-96292a1bd64fec83bb6cdd2480a755b6.tif) seems to be due to a corrupted file.

The Fax4Decode issue is due to an error in the codestream resulting in libtiff not initializing some bytes in the scanline, resulting in later complaints from valgrind when those bytes are used. I can eliminate the complaint by doing a memset to zero on the buffer before passing it to libtiff but that is only covering-up the issue and slows execution.

The out of memory issue (when running valgrind) seems rather severe. It is due to a requested scanline size of 1,701,274,994 bytes. Testing was done on a 64-bit system with 48GB of RAM. Without valgrind, there is no out of memory issue and an error is returned. This is a case where additional memory limits-handling within GraphicsMagick could help.

Any valgrind glitch which is not caused by libtiff (or the libraries it uses) can be blamed on the libtiff utilities. ;-)

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/