Page MenuHomePhabricator

CastToItk behavior is inconsistent
Closed, ResolvedPublic

Description

CastToItk behaves differently depending on the original data type and the target data type:
if the target type is the same as the original, only a pointer to the data is set
thus increasing the reference count, whereas if the data types differ a new itk image is created, and the reference counter to the original image remains the same.

This will cause problems where the modified data is converted back to Mitk using
GrabItkImageMemory - upon descruction of the original image the reference counts seem to be wrong and the program crashes.

Dirty quickfix so far is not to perform a GrabItkImageMemory if the data type is the same as the target (CastToItk).

This is a undefiend behavior that will result in nasty bugs/crashed

Event Timeline

Add minimal test case to reproduce behavior run
./MitkCoreTestDriver mitkImageToItkTest
with non double image , and everything is fine,
run it with a double image and it will crash

User webechr has pushed new remote branch:

bug-17538-MinimalTestExample

In the minimal example, the situation is the following:

  • the TestImageToItkAndBack makes a call to mitk::Image::GrabItkImageMemory

here, on l. 160 resultImage = mitkImage

the resultImage is assigned the original image pointer and in consequence, the reference count of the mitkImage pointer is 4 when leaving the GrabItkImageMemory scope and then 1 in the scope of the main() function of the test.

In consequence, there is a duplicated attempt to delete the image's data.

Adding dependency to 17163 which handles the behavior of the GrabItkImageMemory function when attempting to import identical pointer.

Christian any comments on this? Is it solved by the fix of #17163 ?

kislinsk claimed this task.