[IGSTK-Users] igstkImageSpatialObject memory management problem

[Luis Ibanez]

Hi Torleif,

Thanks for testing the code.

--

As you suggested, I added the std::cout statement in line 92 of
VolumeManager.cpp, and also add a test for the MRLiver dataset.


Here is what I found:


1) The dataset E000192 fails (with a standard State machine transition)
    but *DO NOT CRASHES*. That is, I don't see the bus error that you
    were reporting on June 19th.


2) The dataset MRLiver works fine. It doesn't report the failure of
    line 92.


Looking at the code, the explanation is quite direct:

You are instantiating the MRImageReader, which only accepts DICOM
from MR modality and rejects any other (e.g. CT). The MRLiver dataset
is an MR, and the E00102 dataset is a CT. Therefore, it is normal
that the reader rejects the E000192 dataset.


I verified that by replacing "MR" with "CT" in the types of the code,
then the inverse effect is observed. That is:  MRLiver fails and
E000192 passes.


What you are seeing as a "silent failure" in this case, is actually
the proper error management by the State Machine of the reader.
Namely, if the DICOM dataset cannot be read, the State Machine
goes to a valid state and emits an event notifying observers that
the reading action was unsuccessful.


----

I would speculate that the bus error in your application is
the result of not having a properly programmed State Machine
at the level of the application. More specifically, I would
suspect that your application is not managing correctly the
situation in which the Reader can not read the DICOM dataset.


Have you added an Observer for the DICOM Error events ?


    DICOMInvalidRequestErrorEvent
    DICOMImageDirectoryEmptyErrorEvent
    DICOMImageDirectoryDoesNotExistErrorEvent
    DICOMImageDirectoryIsNotDirectoryErrorEvent
    DICOMImageDirectoryDoesNotHaveEnoughFilesErrorEvent
    DICOMImageSeriesFileNamesGeneratingErrorEvent
    DICOMImageReadingErrorEvent


Are you converting this event into an input to the state
machine of your application ?



If your application is predisposed to the assumption that
the reading is successful, and it is attempting to use the
(supposedly) read image, it is to expect that other classes
will crash down the line (certainly the VTK classes that
expect to have image data to render...).

Looking back at your email from June 19th, the crash actually
happens in the garbage collection of VTK, which indicates that
the VTK pipeline was in an inconsistent state.


---


If your application had a State Machine programmed correctly,
you should have a Transduction macro that converts the events
from the DICOMReader into Inputs to your application's State
Machine.


A) The successful reading event should be converted into an
    input to the State Machine of your application that will
    trigger a transition enabling the classes that require
    the input image to be present in memory (e.g. viewers...).
    Only at this point the viewer could be connected to images.


B) There should be also a transduction macro that converts
    the Error events from the DICOM reader into inputs to the
    State Machine of your application, and presumably you will
    have a transition for that input that will trigger as response
    a message displayed to the user, (something like "Sorry, I couln't
    read your image, because of ...") and a return to one of the
    states that allow the user to attempt to load the image again.
    (maybe by providing a different filename/directory name).



--


To summarize,

A) I still don't observe any crash in this code

B) The error condition of having incorrect image modality
    in the input DICOM dataset is managed correctly by the
    State Machine of the DICOM reader.


It seems that you are prematurely connecting an ImageSpatialObject
to an ImageSpatialObjectRepresentation. That is, connecting an
image to an image viewer, before actually having image data
loaded into memory.



    Regards,


       Luis



----------------------
Torleif Sandnes wrote:
> Hi again.
> Thanks for looking into this!
> 
>> When I run the tests, I don't encounter the error that you reported.
>> so I'm wondering if something platform specific is going on here...
> 
> 
> I compiled the sourcefiles I got from you, and ran the tests. The  error 
> was present on my local MR dataset  /Users/tosa/svn/CustusXdata/ 
> Nevro/MRT1, but no error was *reported* on the MR dataset /IGSTK/ 
> Testing/Data/Input/E000192, but it fails silently before the image is  
> loaded. (Try adding a std::cout line in VolumeManager.cpp:92)
> 
> I also tried loading the IGSTK dataset IGSTK/Testing/Data/Input/ 
> MRLiver. This failed in the way I described earlier. Maybe you could  
> try to load this dataset to see if it works at your computer?
> 
> I am using gcc-4.0.1 on MacOsX 10.4.10.
> itk version 3.0.1
> vtk cvs checkout from april/may
> igstk sandbox checkout from mars/april.
> 
> I should probably bring itk and igstk versions up to date, but I  don't 
> know if that really is the problem.
> 
> Torleif
>