Created attachment 482792 [details] Tiff file used to recreate the problem Description of problem: libtiff was recently updated in RHEL 5.6. It seems that tiffcp is returning fatal errors on some tiff files. The previous version of tiffcp/libtiff either ignored these errors or the tiff file does not actually have the errors that are being reported with the latest update. The output tif image created with the updated tiffcp is corrupt and does not get generated properly. Version-Release number of selected component (if applicable): 3.8.2-7.el5_6.6 How reproducible: Every time with attachment. Steps to Reproduce: 1. With the attached tiff file, run the following command: tiffcp tiffcp_test.TIF output.tif Actual results: Fatal error messages and Warnings such as Fax4Decode: tiffcp_test.TIF: Bad code word at line 256 of strip 0 (x 170). Fax4Decode: Warning, tiffcp_test.TIF: Premature EOL at line 256 of strip 0 (got 170, expected 1696). Fax4Decode: tiffcp_test.TIF: Bad code word at line 257 of strip 0 (x 157). Fax4Decode: Warning, tiffcp_test.TIF: Premature EOL at line 257 of strip 0 (got 157, expected 1696). Expected results: Only warning messages such as: TIFFReadDirectory: Warning, tiffcp_test.TIF: unknown field with tag 33000 (0x80e8) encountered. Additional info: Sending the "-i" tag will ignore the warnings, but it still fails on the fatal errors. As a temporary "fix", I was able to "yum downgrade libtiff" to the previous build (3.8.2-7.el5_5.5).
AFAIK, a TIFF file that triggers those warnings *is* corrupt. Where did you get this file from? Are there tools that display it without complaints?
This is a file that I pulled from one of my servers that I needed to send to a customer of mine. Originally, it was a scanned invoice with a barcode. We generally use tiffcp to combine multi-paged documents into one image. You can view the image in any image reader (though I've been using Microsoft Office Document Imaging so I can easily view multiple pages). This image is only 1 page. The original image looks fine in any image reader. If you use a downgraded version of tiffcp, the output tif file can be viewed as well. Sending the "-i" tag with the latest tiffcp will produce about half an image here when the output file is viewed. Not all tiff files produce fatal errors. I couldn't pinpoint a common thread of what would cause one file to fail and one to succeed. I can provide additional tiff files that fail (or ones that are successful) using tiffcp if it would be helpful.
Well, you have a broken scanner that is outputting illegally-coded fax data; specifically it's trying to emit zero-length runs, which are physically impossible given the specifications of the fax standards (since a run is defined as the distance from a pixel to the next pixel of the opposite color). I would suggest you contact the scanner manufacturer for a fix. We're not going to revert the libtiff change because it is closing a buffer overrun vulnerability. Illegally coded data of almost exactly this form can be exploited to make unpatched libtiff stomp all over memory :-(
Sigh ... you're right, this is a real bug. It appears to be the same case as in this upstream report: http://bugzilla.maptools.org/show_bug.cgi?id=2297
Thanks for taking a look at this, Tom. If you need any additional information from me or if you needed more example tiff files to work with, I have hundreds that I've run across from various customer scans.
This is fixed as of next update, should be out shortly. *** This bug has been marked as a duplicate of bug 688825 ***