2013.09.03 01:18 "Re: [Tiff] Slightly corrupted tiff image causes libtiff to crash with double free or corruption", by Lee Howard
On 09/01/2013 07:30 PM, Lee Howard wrote:
On 09/01/2013 06:05 PM, Konstantin wrote:
I think the same that HylaFAX ist just forwarding the data it receives from the fax modem. I wouldn't say that it's wrong to set the tags according to the JBIG header as this is the only thing that can be done without actually decoding the image. Probably it just got bad data due to some glitch in transmission/reception and maybe HylaFAX and/or the modem didn't care or didn't detect this.
I would like to see the HylaFAX session log associated with this fax as well as the resulting tif image file directly from recvq.
I suspect that this thread is going off-topic for the Tiff mailing list, so my apologies to the list readers, but to not leave any loose-ends for those who may read this later...
Steve and Konstantin are correct. When receiving a fax HylaFAX does not decode the JBIG data in order to deduce the line count. Rather, it just looks at the JBIG data stream and looks for the BIH and NEWLEN markers which indicate the image length. As HylaFAX relies on the jbigkit library for dealing with JBIG data I am no expert when it comes to that data format.
In the HylaFAX session log that Konstantin sent to me I see nothing unusual about the detection of the image length from the BIH markers:
Aug 27 13:21:43.61: [ 6054]: RECV: 14848 bytes of data, 1154 total lines
Aug 27 13:21:53.70: [ 6054]: RECV: 10496 bytes of data, 1153 total lines
Aug 27 13:22:11.14: [ 6054]: RECV: 23040 bytes of data, 1152 total lines
Aug 27 13:22:28.66: [ 6054]: RECV: 23296 bytes of data, 1149 total lines
Aug 27 13:22:37.96: [ 6054]: RECV: 9216 bytes of data, 1150 total lines
Aug 27 13:22:48.65: [ 6054]: RECV: 11520 bytes of data, 1152 total lines
Aug 27 13:22:59.79: [ 6054]: RECV: 12288 bytes of data, 1156 total lines
Aug 27 13:23:06.48: [ 6054]: RECV: 4504 bytes of data, 1155 total lines
The TIFF tags in the tif files that Konstantin sent to me match the image-length detection that HylaFAX made from the BIH marker (1152 and 1149 for pages #3 and #4).
If the image data in the JBIG data actually exceeded these values, then the sender's system erred in the produced BIH marker. As HylaFAX deliberately attempts to preserve the data as-sent by the sender in this case I do not believe that this should be considered a HylaFAX bug. The bug would be with the sender. If libtiff crashes on processing such a tif, then that's a bug in libtiff and not with HylaFAX.