AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2000.03.15 17:44 "Some CCITT Group 3 TIFFs crash libtiff", by Jason Summers
2000.03.15 18:00 "Re: Some CCITT Group 3 TIFFs crash libtiff", by Frank Warmerdam
2000.03.17 16:42 "Re: Some CCITT Group 3 TIFFs crash libtiff", by Jason Summers
2000.03.17 18:34 "Re: Some CCITT Group 3 TIFFs crash libtiff", by Frank Warmerdam
2000.03.27 17:04 "Re: Some CCITT Group 3 TIFFs crash libtiff", by Nalin Dahyabhai
2000.03.15 18:36 "Re: Some CCITT Group 3 TIFFs crash libtiff", by Helge Blischke
2000.03.17 16:51 "Re: Some CCITT Group 3 TIFFs crash libtiff", by Jason Summers
2000.03.17 17:24 "Re: Some CCITT Group 3 TIFFs crash libtiff", by Peter Smith
2000.03.21 14:57 "Re: Some CCITT Group 3 TIFFs crash libtiff", by Thad Humphries
2000.03.21 21:23 "Re: Some CCITT Group 3 TIFFs crash libtiff", by Rick LaMont
2000.03.22 06:08 "Re: Some CCITT Group 3 TIFFs crash libtiff", by Tom Lane

2000.03.17 16:51 "Re: Some CCITT Group 3 TIFFs crash libtiff", by Jason Summers

I've encountered several CCITT Group 3-compressed TIFF images that cause programs compiled with libtiff 3.5.4 to crash with an IPF/segmentation fault.

The files are corrupt.

I agree that they are not completely valid.

(Aside: However, it's difficult to convince end users of this, since most image viewers display these files without even a warning, and the image appears correct to the naked eye.)

I've been assuming that libtiff should not crash when it encounters an invalid file. Right?

Here an error log from tiffcp (from the 3.4beta37 distribution):

RowsPerStrip (278) LONG (4) 1<4294967295> <--- where does this bogusvalue come from?

Beats me. I didn't create the files; they were sent to me by two unrelated persons. But I'd have to guess that it comes from:

Software (305) ASCII (2) 28<HylaFAX (tm) Version 4.0pl2\000>

It's conceivable that something else subsequently corrupted them, but I doubt it.

Jason Summers
jason@med-web.com http://home.mieweb.com/jason/