ITK access violation error in release mode but not in debug mode while reading DICOM files

Question

Well I know many have this problem of Release VS. Debug mode. I have searched a lot and went through stack trace of my program and checked pointers. However, I cannot understand why do I get Access Violation error in Release mode while my program works perfectly in Debug mode! I saw after some steps deep in ITK code suddenly a function causes access violation. I will first present my code, then the calling hierarchy that causes this access violation:

Here are my type definitions:

//typedef unsigned char PixelType;
const unsigned int dimention = 3;

//STD types
typedef std::vector<std::string> FileNamesContainer;
typedef std::vector<std::string> SeriesUIDContainer; 

//ITK Types
typedef itk::DICOMSeriesFileNames NamesGeneratorType;
typedef itk::Image <signed short, dimention> ImageType; //Defining Image Type
typedef itk::ImageSeriesReader<ImageType> ReaderType; //Defining the type of the image series reader

//GDCM Types
typedef itk::GDCMImageIO DICOMImageIOType;

Here is my function:

ReaderType::Pointer itkReadDICOM::ReadImages(char *sourceFolderAddress, std::string &seriesUID)
{
    std::cout<<"- Getting file names in: "<<sourceFolderAddress<<std::endl;
    std::cout<<"- Series ID: "<<seriesUID<<std::endl;

    //Creating a pointer to an object of the reader type. ReaderType is defined on top as itk ImageSeriesReader
    ReaderType::Pointer reader = ReaderType::New();

    //Setting the IO type by creating a dicomIO object from the GDCMImageIO. This will make sure we read DICOM images.
    DICOMImageIOType::Pointer dicomIO = DICOMImageIOType::New();
    reader->SetImageIO(dicomIO);

    //Creating a dicom series name generator. It will generate the name of the dicom series based on the input directory.
    NamesGeneratorType::Pointer namesGenerator = NamesGeneratorType::New();
    namesGenerator->SetDirectory(sourceFolderAddress);

    //Getting names and passing the names to the reader to read them.
    FileNamesContainer fileNames = namesGenerator->GetFileNames(seriesUID);
    reader->SetFileNames(fileNames);

    std::cout<<"- Reading files ... ";

    //Adding a reading progress observer to the reader so we can see how are we reading.
    ITKCmdProgressObserver::Pointer progressObserver = ITKCmdProgressObserver::New();
    reader->AddObserver(itk::ProgressEvent(), progressObserver);

    //Actually reading the files here. If any error happens it will be Printed and the program exists. 
    try
    {
        reader->UpdateLargestPossibleRegion();
        std::cout<<"Successfully read "<< fileNames.size() <<" file(s)."<<std::endl;
    }
    catch  (itk::ExceptionObject &ex)
    {
        std::cout<<"Failed."<<std::endl<<"*********************************************************************"<<std::endl;
        std::cout<<ex<<std::endl;
        std::cout<<"*********************************************************************"<<std::endl;
        return 0;
    }
    return reader;
}

The call causing error is this:

reader->UpdateLargestPossibleRegion();

The above function call goes through this chain of calls that finally cause error:

1.

this->UpdateOutputInformation(); //void ProcessObject::UpdateLargestPossibleRegion()

2.

this->GenerateOutputInformation(); //void ProcessObject::Update()

3.

reader->UpdateOutputInformation(); //template <class TOutputImage> void ImageSeriesReader<TOutputImage>::GenerateOutputInformation(void)

4.

this->GenerateOutputInformation(); //void ProcessObject::UpdateOutputInformation()

5.

m_ImageIO->SetFileName(m_FileName.c_str());
m_ImageIO->ReadImageInformation(); //template <class TOutputImage, class ConvertPixelTraits> void ImageFileReader<TOutputImage, ConvertPixelTraits> ::GenerateOutputInformation(void)

On step 5 the first line is fine and the second line causes access violation. It does not even let me step through it. I am using Visual Studio 2010. I appreciate your answers.

Answer 1

Thanks Paolo for your answer. I tried several things in parallel until now I found the solution! I couldn't really get gflags to run my program though but since I had a gut feeling that problem is not really in the code I didn't invest too much time on it.

Anyways here is what I did and SOLVED the problem:

I downloaded a sample from ITK website called resampleDICOM and compiled it and had the exact same problem. So initially I thought it is an ITK bug. Then I recompiled ITK in release mode with debug (RelWithDebInfo) so I can go into ITK code while debugging in release mode. To my surprise a completely valid pointer related to GDCMImageIO::MetaDataDictionary was suddenly turning to a bad pointer () without any code affecting it. So I realized there should be a heap corruption somewhere! I also knew whatever is causing this corruption cannot be in my code.

So I read in so many threads that mixing Debug and Release .lib and .dll files can makes things really nasty. But I was sure that I am using ITK release .lib files and .dll files since I checked them many times! and I mean MAAANY times! I was about to jump down from balcony and put an end to this misery that I had this idea just to make sure that nothing in debug compilation of ITK is being used by my program. So I changed the name of ITK debug folder to something else and ran my program in release mode and suddenly:

ITKCommon.dll is missing!

Despite the fact that I set all the folders and all settings in visual studio to use the release folder, my program was using ITKCommon.dll at runtime from the debug folder. So I copied the the ITKCommon.dll from the release build into my release folder and voila! My program worked like a charm.

Answer 2

Try using gflags (available in the debug tools of WinSDK) or appverifier (I think it is also in the winsdk).

When enabling gflag on your app (in debug mode) it will spot all the nasty things that happen with the memory and raise a breakpoint as soon as something bad happen