Description
The following bug was encountered when using the conda forge package of ITK, but it will occur on when building on Windows with external libTIFF in general.
When using ITK 5 built with external libTIFF certain TIFF files will cause TIFFImageIO to crash when reading their tags. Specifically inside TIFFImageIO::ReadImageInformation() and then the private TIFFImageIO::ReadTIFFTags().
There is a workaround for versions 4.0.0-4.0.2 of libTIFF based on the value of ITK_TIFF_HAS_TIFFFieldReadCount. This macro define is from Modules/ThirdParty/TIFF/CMakeLists.txt via check_type_size(TIFFFieldReadCount ITK_TIFF_HAS_TIFFFieldReadCount). The CMake function check_type_size uses sizeof(TIFFFieldReadCount) to determine if the function exists or not. However this is not legal to use function types in sizeof according to the standard. GCC and Clang accept this by default for C programs (and rejects it by default for C++) but MSVC rejects it. The correct form would be sizeof(&TIFFFieldReadCount) and check_type_size(&TIFFFieldReadCount ITK_TIFF_HAS_TIFFFieldReadCount).
This means that on Windows with external libTIFF the wrong code is used for accessing TIFF fields. The workaround reproduces internal libTIFF structures that are no longer correct and invalid data is read. In my case it read a 0 into field_name and crashes later when attempting to deference the null pointer while logging that the data type is unsupported.
Attached is a file that reproduces this issue.
itk_crash.zip
Steps to Reproduce
conda install libitk-devel=5.4.5
cmake_minimum_required(VERSION 3.30)
project(itk_crash LANGUAGES CXX)
add_executable(itk_crash main.cpp)
find_package(ITK REQUIRED COMPONENTS ITKIOTIFF)
target_link_libraries(itk_crash PRIVATE ITKIOTIFF)
#include <itkTIFFImageIO.h>
int main()
{
itk::TIFFImageIO::Pointer imageIO = itk::TIFFImageIO::New();
imageIO->SetFileName("./itk_crash.tif");
imageIO->ReadImageInformation();
}
Expected behavior
No crash but should have this error message.
WARNING: In C:\P\IPP\ITK-source\ITK\Modules\IO\TIFF\src\itkTIFFImageIO.cxx, line 1264
TIFFImageIO (0000020FE6411100): ICC Profile has unsupported data type (7) for meta-data dictionary.
Actual behavior
If attached to debugger:
Exception thrown at 0x00007FFC40F55F31 (ucrtbase.dll) in itk_crash.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
Reproducibility
100%
Versions
ITK 5.4.5
conda-forge/win-64::libitk-5.4.5-hb27c29c_0
conda-forge/win-64::libitk-devel-5.4.5-h7f67dcf_0
conda-forge/win-64::libtiff-4.7.1-h8f73337_1
Environment
Windows
Python 3.12
conda 24.1.2
Additional Information
None
Description
The following bug was encountered when using the conda forge package of ITK, but it will occur on when building on Windows with external libTIFF in general.
When using ITK 5 built with external libTIFF certain TIFF files will cause
TIFFImageIOto crash when reading their tags. Specifically insideTIFFImageIO::ReadImageInformation()and then the privateTIFFImageIO::ReadTIFFTags().There is a workaround for versions 4.0.0-4.0.2 of libTIFF based on the value of
ITK_TIFF_HAS_TIFFFieldReadCount. This macro define is fromModules/ThirdParty/TIFF/CMakeLists.txtviacheck_type_size(TIFFFieldReadCount ITK_TIFF_HAS_TIFFFieldReadCount). The CMake functioncheck_type_sizeusessizeof(TIFFFieldReadCount)to determine if the function exists or not. However this is not legal to use function types insizeofaccording to the standard. GCC and Clang accept this by default for C programs (and rejects it by default for C++) but MSVC rejects it. The correct form would besizeof(&TIFFFieldReadCount)andcheck_type_size(&TIFFFieldReadCount ITK_TIFF_HAS_TIFFFieldReadCount).This means that on Windows with external libTIFF the wrong code is used for accessing TIFF fields. The workaround reproduces internal libTIFF structures that are no longer correct and invalid data is read. In my case it read a 0 into
field_nameand crashes later when attempting to deference the null pointer while logging that the data type is unsupported.Attached is a file that reproduces this issue.
itk_crash.zip
Steps to Reproduce
Expected behavior
No crash but should have this error message.
Actual behavior
If attached to debugger:
Reproducibility
100%
Versions
ITK 5.4.5
conda-forge/win-64::libitk-5.4.5-hb27c29c_0
conda-forge/win-64::libitk-devel-5.4.5-h7f67dcf_0
conda-forge/win-64::libtiff-4.7.1-h8f73337_1
Environment
Windows
Python 3.12
conda 24.1.2
Additional Information
None