AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2020.07.16 21:04 "[Tiff] program crashing when using TIFFClientOpen API during closing the file.", by Upanita Goswami
2020.07.16 22:15 "Re: [Tiff] program crashing when using TIFFClientOpen API during closing the file.", by Bob Friesenhahn
2020.07.16 23:12 "[Tiff] Fw: program crashing when using TIFFClientOpen API during closing the file.", by Upanita Goswami
2020.07.17 13:01 "Re: [Tiff] Fw: program crashing when using TIFFClientOpen API during closing the file.", by Bob Friesenhahn
2020.07.17 14:24 "Re: [Tiff] Fw: program crashing when using TIFFClientOpen API during closing the file.", by Upanita Goswami
2020.07.17 18:22 "Re: [Tiff] Fw: program crashing when using TIFFClientOpen API during closing the file.", by Bob Friesenhahn

2020.07.16 21:04 "[Tiff] program crashing when using TIFFClientOpen API during closing the file.", by Upanita Goswami

Hi libTIFF group,

We are from MathWorks, and we are trying to use the TIFFClientOpen API to open/read a TIFF File. When closing the file we occasionally run into a segmentation violation. Debugging through the libTIFF library showed that the crash happens inside TIFFCleanup function when calling the very last _TIFFFree() function inside TIFFClean() before existing TIFFCleanup.

_TIFFFree() simply frees the TIFF pointer using standard library's free function. The crash happens before even our close callback gets a chance to get invoked; which we register with libTIFF library using TIFFClientOpen API.

One suspicion is that the variable clientdata which of type thandle_t points to memory allocated by our code using 'new' and during _TIFFFree, the libTIFF library tries to free the memory pointed by thandle_t using 'free' leading to the crash. So we tried to not use thandle_T at all; .i.e. do not allocate memory on our side and pass a pointer to that memory to libTIFF (to prevent deallocation of resources we do not want to be deallocated) but unfortunately there is still a crash in the same place and so I am not sure anymore.

Stack Trace (from fault):
[ 0] 0x00007fbdedef4fff gsignal+00000207 at /lib/x86_64-linux-gnu/libc.so.6+208890 (no debugging symbols found)
[ 1] 0x00007fbdedef642a abort+00000362 at /lib/x86_64-linux-gnu/libc.so.6+214053 (no debugging symbols found)
[ 2] 0x00007fbdedf32c00 [unknown function] at /lib/x86_64-linux-gnu/libc.so.6+461819 (no debugging symbols found)
[ 3] 0x00007fbdedf38fc6 [unknown function] at /lib/x86_64-linux-gnu/libc.so.6+487361 (no debugging symbols found)
[ 4] 0x00007fbd5063af58 TIFFCleanup at??:? (in libtiff.so.5)
[ 5] 0x00007fbd5063b141 TIFFClose at??:? (in libtiff.so.5)

This is pretty consistent in Linux but not in MAC and Windows. Is this a known issue? How to resolve this? Our libTIFF version is 4.1.0.

Thanks,
Upanita