2007.07.13 18:14 "[Tiff] Read warnings in TIFFReadEncodedStrip lead to crash on TIFFClose", by Steve Bougerolle

2007.07.16 11:51 "Re: [Tiff] Read warnings in TIFFReadEncodedStrip lead to crash onTIFFClose", by Joris Van Damme


We've run into an obscure bug/feature: when reading some specific TIFF files

Fax4Decode (called from TIFFReadEncodedStrip) will toss out a few warnings about "line length mismatch" and continue reading. However, farther down the

line the program segfaults while doing TIFFClose().

The program seems to be doing everything right that I can see - reading the fields

in the right order, checking error return values. The problem is libtiff only DISPLAYS

this warning but doesn't return any error code. If this can cause a segfault, surely it

needs to be classed as an error?

Adding "return -1" to the CLEANUP_RUNS macro in libtiff/tif_fax3.h seems to fix the


FAX 4 decoding, in my opinion, should abort on line length mismatch. If it does try and recover, it should do so by trying to resynchronize, by trying to find the next block of data that decodes as a number of lines fully flawlessly, as does AsTiff. LibTiff does not aboirt, nor does it try to resynchronize. It just continues, and, best case scenario, it may actually resynchronize further down the road. Due to the artefacts of FAX 4 coding, that resynchronization-by-accident, LibTiff style, is actually likely to happen sooner or later, so the strategy does make some sense. That's the rationale behind this being a warning and not an error.

Of course, actual crashes should not happen. We ought to regard this a bug, even if we don't change said warning and resynchronisation-by-accident behaviour. Could you please send me a file of yours that leads to such a segfault?

Best regards,

Joris Van Damme
Download your free TIFF tag viewer for windows here: