Segmentation Fault style error during Casting

Hi there

I’m debugging some code to perform a process on 3D MRI data and I’m getting hung up on a crash I keep encountering when my application is performing a type cast from an unsigned short image to a float.

The relevant snippet of code is as follows:
indent preformatted text by 4 spaces
typedef unsigned short InputPixelType;
typedef float OutputPixelType;

const unsigned int dims = 3;

typedef itk::Image<InputPixelType, dims> InputImageType;
typedef itk::Image<OutputPixelType, dims> OutputImageType;

// Import the image data from pointer
typedef itk::ImportImageFilter<InputPixelType, dims> ImportFilterType;
ImportFilterType::Pointer importFilter = ImportFilterType::New();

// Set up region, spacing, origin, direction etc… (not included to save space)

// m_pSrc is an unsigned short pointer to image data
// m_size is the size (in pixels) of the image dataset
const bool LetImageContainerManageMemory = true;
importFilter->SetImportPointer(m_pSrc,m_size, LetImageContainerManageMemory);


// Now cast the image
typedef itk::CastImageFilter<InputImageType, OutputImageType> CastFilterType;
CastFilterType::Pointer castFilter = CastFilterType::New();

 indent preformatted text by 4 spaces

Upon calling castFilter->Update(), I get a crash which looks like a segmentation fault type of crash. (in reality, I have the Update() call in a try-catch block); does anyone have any suggestions as to why this may be occurring? Are there extra steps I can take to ensure the cast performs safely?

This may be relevant but this algorithm is being performed in a separate thread; I don’t know how well ITK calls handle being placed into worker threads.

Thank you!

Hi @WillScottJackson,

I don’t see any definition of ImagePixelType in your snippet. Maybe you rather wanted to put OutputPixelType?


Ah yes, thank you! Have edited accordingly!

Is the caught error of type ExceptionObject ? If so, what does it say ?

1 Like

It doesn’t catch any error. Instead I get hard crash with no information being printed to my console.

try {
} catch (itk::ExceptionObject & err) {
std::cout << “ExceptionObject Caught!” << std::endl;
std::cout << err << std::endl;
return false;

It leaves me to suspect something goes wrong inside Update() which kills the application rather than any error handling catching it and reporting it back to my exception handler.

Which version of ITK are you using? Some stable release or a recent master version? Have you tried stepping through it with a debugger to see where the error is happening?

It is fairly old, version 4.7 is the one I’m working with.

I’m not having the easiest time debugging as the function I’m working with is being built into a .dll file and running through a GUI front end.

(I’m debugging an existing code base rather than writing it myself from scratch, hence the awkward set up)

I’ve even done some couts just to see what happens:

std::cout << "Type Cast Set up" << std::endl;

try {
} catch (itk::ExceptionObject & err) {
	std::cout << "ExceptionObject Caught!" << std::endl;
	std::cout << err << std::endl;
	return false;

std::cout << "Type Cast Successful" << std::endl;

And the console returns this:
Type Cast Set up
The program ‘[5644] TestViewer.vshost.exe: Managed’ has exited with code -529697949 (0xe06d7363).

As the test application has crashed and has to close.

Is the error can be caught at all with:
{ castFilter->Update() }
catch (…)
{ std::cout<<“Something was caught” }

If so, the error should be trackable in the code. But anyhow I don’t know if you can do so without access to debugging.

I managed to catch the exception, I got thrown:
Access Violation - no RTTI Data!

Although the standard itk::ExceptionObject didn’t work.

Perhaps you have multiple versions of ITK on your system? This could be a sign that you are including one version but linking ( runtime or compile ) to another.

1 Like

I’ve been crawling over my Visual Studio set up. As far as I can tell, everything is correctly referenced. I am building with 4.7 libraries and am linking with 4.7 libraries. The only thing I can think of at the moment is maybe the initial build had some options unchecked when building with CMake.