sitkUtils.PullVolumeFromSlicer makes Slicer crash

Fernando · January 12, 2020, 1:11pm

Hi all,

Snippet to reproduce:

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

Tried on latest nightly for macOS: r28728.

Fernando · January 12, 2020, 1:22pm

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

@blowekamp

jamesobutler · January 12, 2020, 8:44pm

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.

pieper · January 12, 2020, 10:39pm

That code works for me on my local mac build.

jamesobutler · January 12, 2020, 10:51pm

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.

pieper · January 12, 2020, 11:13pm

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*) ()

lassoan · February 1, 2020, 4:19pm

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?

pieper · February 1, 2020, 4:45pm

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.

blowekamp · February 3, 2020, 4:18pm

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.

pieper:

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*) ()

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](BUG: Fix SimpleITK failure to convert between SimpleITK and ITK image… · Slicer/Slicer@506754f · GitHub
#diff-109aeb3808fbb9cd5a014863e7556a16R72) for SimpleITK which tries to do more intelligent or user friendly automatic configuration of required flags and libraries.

Sam_Horvath · February 3, 2020, 4:31pm

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

blowekamp · February 3, 2020, 4:34pm

More specifically what is CMAKE_OSX_SYSROOT and CMAKE_OSX_DEPLOYMENT_TARGET?

Sam_Horvath · February 3, 2020, 4:36pm

From top level build cache:

//Build architectures for OSX
CMAKE_OSX_ARCHITECTURES:STRING=

CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.11

//The product will be built against the headers and libraries located
// inside the indicated SDK.
CMAKE_OSX_SYSROOT:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk

blowekamp · February 3, 2020, 5:52pm

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

Sam_Horvath · February 3, 2020, 5:58pm

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.

blowekamp · February 3, 2020, 10:38pm

Thanks for checking.

I am able to use the PythonSlicer executable successfully:

./Slicer-4.11.0-2020-01-30.app/Contents/bin/PythonSlicer -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.

Sam_Horvath · February 4, 2020, 3:09pm

Interesting. According to a current failing test( http://slicer.cdash.org/testDetails.php?test=9874258&build=1815371),

/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.

blowekamp · February 4, 2020, 4:04pm

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/Slicer.app/Contents/lib/Python/lib/python3.6/site-packages/SimpleITK-1.3.0.dev527-py3.6-macosx-10.11-x86_64.egg/SimpleITK/SimpleITK.py", 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?

Sam_Horvath · February 4, 2020, 4:12pm

They appear to be static for macOS release:

github.com

Slicer/Slicer/blob/4db181a73e03b3a2c8044ffd4e4174d873b267c3/CMakeLists.txt#L341




#
# SimpleITK has large internal libraries, which take an extremely long
# time to link on windows when they are static. Creating shared
# SimpleITK internal libraries can reduce linking time. Also the size
# of the debug libraries are monstrous. Using shared libraries for
# debug, reduce disc requirements, and can improve linking
# times. However, these shared libraries take longer to load than the
# monolithic target from static libraries.
#
set( Slicer_USE_SimpleITK_SHARED_DEFAULT OFF)
string(TOUPPER "${CMAKE_BUILD_TYPE}" _CMAKE_BUILD_TYPE)
if(MSVC OR _CMAKE_BUILD_TYPE MATCHES "DEBUG")
  set(Slicer_USE_SimpleITK_SHARED_DEFAULT ON)
endif()
CMAKE_DEPENDENT_OPTION(Slicer_USE_SimpleITK_SHARED "Build SimpleITK with shared libraries. Reduces linking time, increases run-time load time." ${Slicer_USE_SimpleITK_SHARED_DEFAULT} "Slicer_USE_SimpleITK" OFF )
mark_as_superbuild(Slicer_USE_SimpleITK_SHARED)


#-----------------------------------------------------------------------------
# Install no development files by default, but allow the user to get
# them installed by setting Slicer_INSTALL_DEVELOPMENT to true.

From SimpleITK build cache on factory:

//Build SimpleITK ITK with shared libraries. This does not effect
// wrapped languages.
BUILD_SHARED_LIBS:BOOL=OFF

blowekamp · February 4, 2020, 4:32pm

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.

pieper · February 4, 2020, 4:36pm

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

Slicer_USE_SimpleITK_SHARED:BOOL=ON

My compiler is the one that comes with Xcode.

Topic		Replies	Views
Did sitkUtils.PullVolumeFromSlicer() break with Slicer 5.2? Development	9	571	February 7, 2023
Reproducible Slicer crash when pushing to some volume nodes using sitkUtils PushVolumeToSlicer Development	3	290	January 29, 2021
Reproducible crash on Nightly (2019-08-29) on trying to view 64 bit image Development	1	208	September 5, 2019
Crash when using Volumes module on Windows 7 after 4.9 version Support	10	1265	September 5, 2018
Slicer program crash suddenly in MacBook Support crash	2	393	November 27, 2022

sitkUtils.PullVolumeFromSlicer makes Slicer crash

Related Topics