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.
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)
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.
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.
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:
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?
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 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).
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!