View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003008 | Slicer4 | Core: CLI infrastructure | public | 2013-03-13 12:12 | 2017-06-07 23:27 |
Reporter | lassoan | Assigned To | jcfr | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | |||||
Target Version | Slicer 4.3.0 | Fixed in Version | Slicer 4.3.0 | ||
Summary | 0003008: Executable CLI modules fail to start | ||||
Description | GrayscaleModelMaker module crashes with the trunk version. Actually, building any CLI module with the EXECUTABLE_ONLY fails the same way. The CLI executable fails to create IO object for a NRRD file (in itkImageFileReader.hxx line 120 m_ImageIO.IsNull() is true) with the following error: Could not create IO object for file C:/Users/lasso/SkyDrive/Projects/SlicerTesting/20130311-GraysTest/IJFG_vtkMRMLScalarVolumeNodeC.nrrd. Tried to create one of the following: AnalyzeImageIO GE5ImageIO. I guess it should try much more IO objects and not just AnalyzeImageIO and GE5ImageIO. | ||||
Tags | No tags attached. | ||||
This is related to the ITKv4 transition - there are some other related bugs, but I can't look them up right now. |
|
Fixed in r21859 BUG: Restore functioning of CLI loadable module by fixing ITKv4 regression Problem is summarize by the discussion posted on the ITK developer list // -------------- Following commit 4c47e7d [1] of February 19th and commit defb9c1 [2] of This caused a regression in Slicer where the ObjectFactory were expected In Slicer case, the environment variable ITK_AUTOLOAD_PATH was set during By commenting line where a new ImageRegionSplitterSlowDimension is An easy solution for us would be to ensure the "ITK_AUTOLOAD_PATH" To provide more details, within Slicer we set the CMake variable It seems the new ITK commits 4c47e7d and defb9c1 prevent from completely [1] https://github.com/Kitware/ITK/commit/4c47e7d [^] // -------------- This is quite an interesting side-effect of the changes I introduced. I am glad that you were able to figure this out. For a variety of I agree that lazy initialization is the way to go. Unfortunately it ITKv4 performs the factory initialization when the user creates the CONCLUSION: Inside ITK, we can not use statically initialized ITK object. Issues: ITK discussion: ITK patch: Fixes 0003008 |
|
The problem is still the same with the latest nightly build (Slicer-4.2.0-2013-04-24-win-amd64): Grayscale model maker (and probably all other EXECUTABLE_ONLY modules) still crashes. |
|
Fixed in r21950 BUG: Ensure ITK IOFactory are registered for EXECUTABLE_ONLY cli modules The library wrapper are now used when compiling either the [executable] or Associated SlicerExecutionModel commit is: // --------------------------------------------------- The macro "MODULE_STATIC" has also been introduced and can be tested Change the component associated with Archive target from RuntimeLibraries |
|
Thanks for the fix! Tested on Slicer 4.2.0-2013-04-30 (Win64) and it works well. |
|
Fix committed to 2145-support-for-installing-extension-from-file branch. |
|
Slicer: 2145-support-for-installing-extension-from-file ca86fc03 2013-04-03 16:17:01 Details Diff |
BUG: Restore functioning of CLI loadable module by fixing ITKv4 regression Problem is summarize by the discussion posted on the ITK developer list reported below. // -------------- Question from Jean-Christophe Fillion-Robin: Following commit 4c47e7d [1] of February 19th and commit defb9c1 [2] of March 1st, due to static initialization, the initialization of ObjectFactory now happens when ITK shared library are loaded [3][4]. This caused a regression in Slicer where the ObjectFactory were expected to be loaded while attempting to load an image for the first time. In Slicer case, the environment variable ITK_AUTOLOAD_PATH was set during the initialization of the qSlicerCoreApplication, which is now too late. By commenting line where a new ImageRegionSplitterSlowDimension is instantiated [5][6] and updating the method "GetImageRegionSplitter / GetGlobalDefaultSplitter" to return 0 [7][8], the initialization can happen on demand instead of when ITK libraries are loaded. An easy solution for us would be to ensure the "ITK_AUTOLOAD_PATH" environment variable is set in the application launcher for Windows and Linux application and set in Info.plist file associated with the application bundle on MacOSX [9] To provide more details, within Slicer we set the CMake variable ITK_NO_IO_FACTORY_REGISTER_MANAGER before doing an "include(${ITK_USE_FILE}) so that IOFactory are loaded only by calling the method "itkFactoryRegistration" associated with a shared library we named ITKFactoryRegistration. This approach allowed us to disable the automatic registration of factory in selected part of the code. More details here [10] It seems the new ITK commits 4c47e7d and defb9c1 prevent from completely leveraging the use of ITK_NO_IO_FACTORY_REGISTER_MANAGER variable, the code should probably be updated to consider this. [1] https://github.com/Kitware/ITK/commit/4c47e7d [2] https://github.com/Kitware/ITK/commit/defb9c1 [3] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L27 [4] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkObjectFactoryBase.cxx#L142-144 [5] https://github.com/Kitware/ITK/blob/defb9c1d084c8d55df61947587427839f9968ecf/Modules/IO/ImageBase/src/itkImageIOBase.cxx#L760 [6] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L27 [7] https://github.com/Kitware/ITK/blob/defb9c1d084c8d55df61947587427839f9968ecf/Modules/IO/ImageBase/src/itkImageIOBase.cxx#L765 [8] https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L32 [9] http://www.herzbube.ch/blog/2009/01/how-set-environment-variables-mac-os-x-applications [10] https://github.com/Slicer/Slicer/commit/03b8961 // -------------- // -------------- Answer from Brad Lowekamp: This is quite an interesting side-effect of the changes I introduced. I am glad that you were able to figure this out. For a variety of reasons, it's likely a very bad thing for all that to occur during static initialization in ITK. So it certainly needs to be fixed. I agree that lazy initialization is the way to go. Unfortunately it needs to be thread safe so its a little more completed. ITKv4 performs the factory initialization when the user creates the first ITK object. And that changed with this patch, and need to be fixed. CONCLUSION: Inside ITK, we can not use statically initialized ITK object. // -------------- Issues: http://www.na-mic.org/Bug/view.php?id=3042 http://www.na-mic.org/Bug/view.php?id=3008 ITK discussion: http://comments.gmane.org/gmane.comp.lib.itk.devel/1133 ITK patch: http://itk.org/gitweb?p=ITK.git;a=commit;h=1679816baef6b95356d9afdd9bd4a481ca08556c http://review.source.kitware.com/#/c/10645/ Fixes 0003008 Fixes 0003042 git-svn-id: http://svn.slicer.org/Slicer4/trunk@21859 3bd1e089-480b-0410-8dfb-8563597acbee |
||
mod - SuperBuild/External_ITKv4.cmake | Diff File | ||
Slicer: 2145-support-for-installing-extension-from-file c4a16fba 2013-04-27 18:35:11 Details Diff |
BUG: Ensure ITK IOFactory are registered for EXECUTABLE_ONLY cli modules The library wrapper are now used when compiling either the [executable] or [executable + shared library] cli module. It allows to call the "itk::itkFactoryRegistration();" in both cases. Associated SlicerExecutionModel commit is: // --------------------------------------------------- ENH: Use library wrapper in the "EXECUTABLE_ONLY" case This will allow custom wrapper to execute some code before the main entry point in both the [exec + shared lib] and [exec only] cases. The macro "MODULE_STATIC" has also been introduced and can be tested within the wrapper to discriminate both cases. Change the component associated with Archive target from RuntimeLibraries to Development. That way, static library won't be packaged. // --------------------------------------------------- See http://na-mic.org/Bug/view.php?id=3008 Fixes 0003008 git-svn-id: http://svn.slicer.org/Slicer4/trunk@21950 3bd1e089-480b-0410-8dfb-8563597acbee |
||
mod - Base/CLI/SEMCommandLineLibraryWrapper.cxx.in | Diff File | ||
mod - SuperBuild/External_SlicerExecutionModel.cmake | Diff File |
Date Modified | Username | Field | Change |
---|---|---|---|
2013-03-13 12:12 | lassoan | New Issue | |
2013-03-13 12:12 | lassoan | Status | new => assigned |
2013-03-13 12:12 | lassoan | Assigned To | => millerjv |
2013-03-21 13:22 | pieper | Note Added: 0008196 | |
2013-04-02 09:36 | lassoan | Summary | GrayscaleModelMaker module fails to start => Executable CLI modules fail to start |
2013-04-03 11:53 | jcfr | Assigned To | millerjv => jcfr |
2013-04-03 11:53 | jcfr | Target Version | => Slicer 4.3.0 |
2013-04-16 15:11 | jcfr | Relationship added | duplicate of 0003042 |
2013-04-16 15:11 | jcfr | Note Added: 0008415 | |
2013-04-16 15:11 | jcfr | Status | assigned => resolved |
2013-04-16 15:11 | jcfr | Fixed in Version | => Slicer 4.3.0 |
2013-04-16 15:11 | jcfr | Resolution | open => fixed |
2013-04-25 16:58 | lassoan | Note Added: 0008508 | |
2013-04-25 16:58 | lassoan | Status | resolved => assigned |
2013-04-27 14:36 | jcfr | Note Added: 0008529 | |
2013-04-27 14:36 | jcfr | Status | assigned => resolved |
2013-05-01 07:50 | lassoan | Note Added: 0008547 | |
2013-05-01 07:50 | lassoan | Status | resolved => closed |
2017-06-07 23:27 | jcfr | Changeset attached | => Slicer 2145-support-for-installing-extension-from-file c4a16fba |
2017-06-07 23:27 | jcfr | Changeset attached | => Slicer 2145-support-for-installing-extension-from-file ca86fc03 |
2017-06-07 23:27 | jcfr | Note Added: 0014644 |