sitkUtils.PullVolumeFromSlicer makes Slicer crash

Hi all,

Snippet to reproduce:

import SampleData
import sitkUtils as su
sampleDataLogic = SampleData.SampleDataLogic()
node = sampleDataLogic.downloadMRHead()

Tried on latest nightly for macOS: r28728.

1 Like

Actually, it seems to be a problem with SimpleITK, as sitk.ReadImage() makes Slicer crash as well.


1 Like

Yes, it appears that py_nomainwindow_test_sitkUtils is failing as you have also reported here. This is likely due to recent updates to ITK and SimpleITK in 28727. That SimpleITK version specifies to use ITK 5.1rc01 which is what we switched to so there in theory shouldn’t be an incompatibility between the two. There had to be a fix to Mac to fix an ITK compile error in the commit after the updated ITK one. Maybe @pieper can look into this on Mac?

I’ll have to test on Windows to see if it is across platforms, but the test appears to be passing on the Windows build machine.

1 Like

That code works for me on my local mac build.

1 Like

Maybe @pieper you can try to install the package from the nightly build machine to see if it is an issue specific to that package? The tests are showing some Slicer crash using that build.

Yes, you are right - the 2020-01-10 build crashes with that input.

I am able to attach Xcode to the release build but there’s not much stack info (maybe it gets trashed) but it says this is the function where the crash occurs:

#0	0x000000013a916aaa in itk::ImageFileReader<itk::Image<short, 3u>, itk::DefaultConvertPixelTraits<short> >::EnlargeOutputRequestedRegion(itk::DataObject*) ()
1 Like

This is a very serious limitation of Slicer on MacOS. I don’t have easy access to a Mac and not know much about MacOS anyway, so someone else has to investigate this.

@pieper what do you think? Can you investigate yourself or do you need help from @blowekamp with SimpleITK or @Sam_Horvath with accessing the factory machine?

I agree it’s a blocker for the slicer5 release. (for reference also see this post).

I’m not seeing a lot of clues to suggest a course of action. I guess I could try making a release build locally and see if I can replicate.

Yes, input from @blowekamp and @Sam_Horvath would be appreciated.

I was able to reproduce this on Slicer-4.11.0-2020-1-30 and Slicer-4.11.0-2020-01-12 ( which was be for this change with regards to the SITK explicit instantiation library.

The lack of symbols is due to the SimpleITK libraries being explicitly striped. This greatly reduces the size of the libraries. Without further clues it may be worth it to set “SimpleITK_BUILD_STRIP=OFF” for the nightly Mac build.

This sounds like it’s a problem only with the nightly builds. What is the current OS, Xcode, and OS SDK used for those builds?

This may be some type of miss match with between flags or libraries between the ITK libraries and the SimpleITK libraries. Slicer is using the [“Superbuild” configuration](
#diff-109aeb3808fbb9cd5a014863e7556a16R72) for SimpleITK which tries to do more intelligent or user friendly automatic configuration of required flags and libraries.

1 Like

Factory Details:

OS: 10.11.6
XCode: 8.2 (but we aren’t building with Xcode. We are building with Clang - clang-800.0.42.1)
XCode SDK: Xcode 8.2.1 Build version 8C1002


1 Like

From top level build cache:

//Build architectures for OSX


//The product will be built against the headers and libraries located
// inside the indicated SDK.

How do these variable get propagated to the Superbuild’s External Projects?

They are provided in the initial cache when configuring external projects.

I have checked, and the cache variables for ITK and SimpleITK match the top level.


Thanks for checking.

I am able to use the PythonSlicer executable successfully:

./ -c \
  "import SimpleITK as sitk; sitk.ReadImage('/Users/blowekamp/cthead1.png')"

But if the same commands are execute in the 3D Slicer REPL, then the program termination occurs.

I wonder if this dynamic_cast is failing.

Interesting. According to a current failing test(,

/Volumes/Dashboards/Preview/Slicer-0-build/Slicer-build/Slicer "--no-splash" "--testing" "--no-main-window" "--additional-module-paths" "/Volumes/Dashboards/Preview/Slicer-0-build/Slicer-build/lib/Slicer-4.11/qt-scripted-modules" "/Volumes/Dashboards/Preview/Slicer-0-build/Slicer-build/lib/Slicer-4.11/cli-modules" "/Volumes/Dashboards/Preview/Slicer-0-build/Slicer-build/lib/Slicer-4.11/qt-loadable-modules" "--python-code" "import slicer.testing; slicer.testing.runUnitTest(['/Volumes/Dashboards/Preview/Slicer-0-build/Slicer-build/Applications/SlicerApp/Testing/Python', '/Volumes/Dashboards/Preview/Slicer-0/Base/Python/tests'], 'test_sitkUtils')"

also generates the error.

So it looks like we are failing when we are specifically in the full Slicer environment, but not the Slicer python interpreter.


The following fails with a verbose message on the nightly build too:

> import SimpleITK as sitk
> img = sitk.Image(10,10,sitk.sitkUInt8)
> sitk.SmoothingRecursiveGaussian(img)

Traceback (most recent call last):

File "<console>", line 1, in <module>

File "/Users/blowekamp/Desktop/", line 64305, in SmoothingRecursiveGaussian

return _SimpleITK.SmoothingRecursiveGaussian(*args)

RuntimeError: Exception thrown in SimpleITK SmoothingRecursiveGaussian: /Volumes/Dashboards/Preview/Slicer-0-build/ITK/Modules/Core/Common/include/itkImage.hxx:131:

itk::ERROR: Image(0x7f8224cf4a50): itk::Image::Graft() cannot cast PKN3itk10DataObjectE to PKN3itk5ImageIfLj2EEE

This confirms is an OSX symbol/dynamic_cast issue.

@Sam_Horvath That further confirms that the Slicer’s runtime is polluting SimpleITK with different ITK symbols than what is expected in the SimpleITK library.

@pieper Are you compiling Slicer with SimpleITK shared or static libraries on OSX?

They appear to be static for macOS release:

From SimpleITK build cache on factory:

//Build SimpleITK ITK with shared libraries. This does not effect
// wrapped languages.

I recall Steve being a fan of compline Slicer in Debug mode. If so then line 343 would have made the libraries be shared by default.

I have not set up a Slicer build environment, and I need to know the requirements for a system setup to reproduce the issue. The nightly build system seems a little exotic with its custom clang compiler.

Yes, my local build is Debug and my CMakeCache.txt says:


My compiler is the one that comes with Xcode.