SlicerRT built from source cannot start

I agree this isn’t optimal. @jcfr could you please confirm whether the QtCreator debugger is expected to work with the current latest version of Slicer? I tried with Qtcreator 17 and 14.0.2 (ubuntu 25.04, gcc 14) and the debugger was not starting.

both should work. I used the GUI.

1 Like

Awesome, thanks for the help in starting gdb.

I am getting this stacktrace now, which helps us spot the issue:

Loading module “ExternalBeamPlanning”
Thread 1 “SlicerApp-real” received signal SIGSEGV, Segmentation fault.
Python Exception <class ‘NameError’>: Installation error: gdb._execute_unwinders function is missing
0x00007fffd8252642 in PyObject_HasAttrString (Python Exception <class ‘NameError’>: Installation error: gdb._execute_unwinders function is missing
v=0x7ffefe3f2840, name=0x5555588418c8 “MockPythonDoseEngine”) at /home/user/builds/build-Slicer_src-Desktop-Debug/Python-3.12.10/Objects/object.c:945
945 if (Py_TYPE(v)->tp_getattr != NULL)

1 Like

Just git-checked out latest Slicer master, now getting while rebuilding SlicerRT in debug mode (Slicer debug rebuild went fine):

[ 6%] Linking CXX shared library ../../lib/Slicer-5.9/qt-loadable-modules/libvtkSlicerBeamsModuleMRML.so
/usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTPlanNode.cxx.o:(.data.rel.ro._ZTV17vtkMRMLRTPlanNode[_ZTV17vtkMRMLRTPlanNode]+0x158): undefined reference to vtkMRMLNode::GetTypeDisplayName[abi:cxx11]()' /usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTPlanNode.cxx.o:(.data.rel.ro._ZTV17vtkMRMLRTPlanNode[_ZTV17vtkMRMLRTPlanNode]+0x160): undefined reference to vtkMRMLNode::SetTypeDisplayName(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)’
/usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTPlanNode.cxx.o:(.data.rel.ro._ZTV17vtkMRMLRTPlanNode[_ZTV17vtkMRMLRTPlanNode]+0x168): undefined reference to vtkMRMLNode::GetDefaultNodeNamePrefix[abi:cxx11]()' /usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTPlanNode.cxx.o:(.data.rel.ro._ZTV17vtkMRMLRTPlanNode[_ZTV17vtkMRMLRTPlanNode]+0x170): undefined reference to vtkMRMLNode::SetDefaultNodeNamePrefix(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)’
/usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTBeamNode.cxx.o:(.data.rel.ro._ZTV17vtkMRMLRTBeamNode[_ZTV17vtkMRMLRTBeamNode]+0x158): undefined reference to vtkMRMLNode::GetTypeDisplayName[abi:cxx11]()' /usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTBeamNode.cxx.o:(.data.rel.ro._ZTV17vtkMRMLRTBeamNode[_ZTV17vtkMRMLRTBeamNode]+0x160): undefined reference to vtkMRMLNode::SetTypeDisplayName(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)’
/usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTBeamNode.cxx.o:(.data.rel.ro._ZTV17vtkMRMLRTBeamNode[_ZTV17vtkMRMLRTBeamNode]+0x168): undefined reference to vtkMRMLNode::GetDefaultNodeNamePrefix[abi:cxx11]()' /usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTBeamNode.cxx.o:(.data.rel.ro._ZTV17vtkMRMLRTBeamNode[_ZTV17vtkMRMLRTBeamNode]+0x170): undefined reference to vtkMRMLNode::SetDefaultNodeNamePrefix(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)’
/usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTIonBeamNode.cxx.o:(.data.rel.ro._ZTV20vtkMRMLRTIonBeamNode[_ZTV20vtkMRMLRTIonBeamNode]+0x158): undefined reference to vtkMRMLNode::GetTypeDisplayName[abi:cxx11]()' /usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTIonBeamNode.cxx.o:(.data.rel.ro._ZTV20vtkMRMLRTIonBeamNode[_ZTV20vtkMRMLRTIonBeamNode]+0x160): undefined reference to vtkMRMLNode::SetTypeDisplayName(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)’
/usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTIonBeamNode.cxx.o:(.data.rel.ro._ZTV20vtkMRMLRTIonBeamNode[_ZTV20vtkMRMLRTIonBeamNode]+0x168): undefined reference to vtkMRMLNode::GetDefaultNodeNamePrefix[abi:cxx11]()' /usr/bin/ld: CMakeFiles/vtkSlicerBeamsModuleMRML.dir/vtkMRMLRTIonBeamNode.cxx.o:(.data.rel.ro._ZTV20vtkMRMLRTIonBeamNode[_ZTV20vtkMRMLRTIonBeamNode]+0x170): undefined reference to vtkMRMLNode::SetDefaultNodeNamePrefix(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)’
collect2: error: ld returned 1 exit status
make[5]: *** [Beams/MRML/CMakeFiles/vtkSlicerBeamsModuleMRML.dir/build.make:167: lib/Slicer-5.9/qt-loadable-modules/libvtkSlicerBeamsModuleMRML.so] Error 1
make[4]: *** [CMakeFiles/Makefile2:2819: Beams/MRML/CMakeFiles/vtkSlicerBeamsModuleMRML.dir/all] Error 2
make[3]: *** [Makefile:166: all] Error 2
make[2]: *** [CMakeFiles/inner.dir/build.make:87: inner-prefix/src/inner-stamp/inner-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:896: CMakeFiles/inner.dir/all] Error 2

I just checked quickly and it seems they changed the value of TypeDisplayName from char* to std::string, may be related.

Hmm could be also that before it was ‘inline’ in the header, and now it’s in the source file? So missing linking to the library?

It might also be some cache issue, I will try wiping out the build dir and rebuilding from scratch.

A full rebuild solved this linker error.

I do still get the runtime crash concerning the MockPythonDoseEngine

Alright, with this diff:

diff --git a/ExternalBeamPlanning/Widgets/Python/CMakeLists.txt b/ExternalBeamPlanning/Widgets/Python/CMakeLists.txt
index 5ce02b92..e4603d84 100644
--- a/ExternalBeamPlanning/Widgets/Python/CMakeLists.txt
+++ b/ExternalBeamPlanning/Widgets/Python/CMakeLists.txt
@@ -7,7 +7,7 @@ configure_file(
 #-----------------------------------------------------------------------------
 set(DoseEngines_PYTHON_SCRIPTS
   AbstractScriptedDoseEngine
-  MockPythonDoseEngine
+  #MockPythonDoseEngine
   EGSnrcUtil
   OrthovoltageDoseEngineUtil
   OrthovoltageDoseEngine
diff --git a/ExternalBeamPlanning/Widgets/Python/DoseEngines.__init__.py.in b/ExternalBeamPlanning/Widgets/Python/DoseEngines.__init__.py.in
index 796a2987..31e4eb18 100644
--- a/ExternalBeamPlanning/Widgets/Python/DoseEngines.__init__.py.in
+++ b/ExternalBeamPlanning/Widgets/Python/DoseEngines.__init__.py.in
@@ -11,7 +11,7 @@ except AttributeError:
 import importlib
 import traceback
 engineNames = [
-  "MockPythonDoseEngine",
+  #"MockPythonDoseEngine",
   "OrthovoltageDoseEngine"
   ]
 for engineName in engineNames:

SlicerRT starts again :slight_smile:

I do get the following warning:

RuntimeError: qSlicerScriptedDoseEngine::setPythonSource - Failed to load scripted dose engine: class OrthovoltageDoseEngine was not found in /opt/SlicerRT_dbg_bld/inner-build/lib/Slicer-5.9/qt-scripted-modules/DoseEngines/OrthovoltageDoseEngine.py

even if that file is there and contains the mentioned class. Weird.

Anyway, at least now I can start and test SlicerRT again.

For future reference, for debugging, I used:

/home/user/builds/build-Slicer_src-Desktop-Debug/Slicer-build/Slicer --launch gdb --args /home/user/builds/build-Slicer_src-Desktop-Debug/Slicer-build/bin/SlicerApp-real --no-splash --launcher-verbose --verbose-module-discovery --launcher-additional-settings /opt/SlicerRT_dbg_bld/inner-build/AdditionalLauncherSettings.ini --additional-module-paths /opt/SlicerRT_dbg_bld/inner-build/lib/Slicer-5.9/qt-scripted-modules /opt/SlicerRT_dbg_bld/inner-build/lib/Slicer-5.9/qt-loadable-modules /opt/SlicerRT_dbg_bld/inner-build/lib/Slicer-5.9/cli-modules

Thank you very much Fernando! Did you do anything other than commenting out the mock engine to fix the crash? Just to know exactly what worked in the end, because it seems strange that a tbb related crash is resolved by excluding a python script.

You are welcome. I did nothing else.

In my case, I did not get any warning about tbb when running gdb.
Maybe, that was an artefact related to the fact that the Slicer tbb:
tbb-install/lib/intel64/gcc4.8/libtbb_debug.so.12

does not play well with a system onetbb installed. I do not have onetbb installed in my system, which explains why I did not get the tbb warning, but I got directly the MockDoseEngine crash. Whereas Davide had this installed:

/localdisk/ci/runner006/intel-innersource/001/_work/libraries.threading.infrastructure.onetbb-ci/libraries.threading.infrastructure.onetbb-ci/onetbb_source_code/src/tbb/exception.cpp

Excluding the mock python engine fixes the crash for me as well. I don’t understand the reason though. I also don’t know why the orthovoltage engine is not loading, but it has not been maintained, and requires some special tools being installed and configured locally, so I am pretty sure nobody uses it currently. Should we commit this workaround to at least have SlicerRT running?

Sounds good to me! Thanks for checking.

Change pushed, see BUG: Exclude MockPythonDoseEngine to fix crash on startup · SlicerRt/SlicerRT@8088306 · GitHub

I’m still getting the same crash 4 out of 5 times. I repeat that I don’t think that omitting a Python dose engine that barely does anything makes sense to fix a crash.

I tried now a couple of times in a row and indeed it sometimes crashes. This is the stack trace:

Python Exception <class 'NameError'>: Installation error: gdb._execute_unwinders function is missing
0x00007fffd813e642 in PyObject_HasAttrString (Python Exception <class 'NameError'>: Installation error: gdb._execute_unwinders function is missing
v=0x7fff0b338c70, name=0x55555b326ba8 "OrthovoltageDoseEngine")

After disabling OrthovoltageDoseEngine (and Utils), now it never crashes. Never = 5 times in a row.

Interesting. Thanks for further looking into it. Could this be related to the Python upgrade? The same thing that causes this problem. @lassoan @jcfr

I pushed a commit with removing the orthovoltage plugin as well.

@ferhue Also pushed a commit that is supposed to fix the build errors with the latest Slicer, so you may need to upgdate your Slicer (or I can add more version checks).

Thanks a lot!

Should I close this PR? FIX: avoid compilation warnings with latest Slicer and VTK9.5 by ferdymercury · Pull Request #276 · SlicerRt/SlicerRT · GitHub

Oh, I missed this. Too many things on my plate lately… OK it seems that most of what your PR did is included in my commit (except for removing the extra spaces from the end of lines).

One difference is that your change fixes the triangulate issue with calling NonDegenerateTriangulate and mine calls EarCutTriangulation. I checked the old VTK code and the new one, and I am pretty sure that what I chose works the same way. Do you have any argument for choosing the one you suggested?

And to your question, I think it can be closed once we discussed this part. Sorry for the confusion about the PR!

Thanks, no problem!

wrt NonDegenerate: it was a suggestion by SlicerRT built from source cannot start - #6 by chir.set so I did not look into the details.