|
Tags: 2017 source edit, Replaced |
| (30 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| − | ==Background==
| + | <noinclude>{{documentation/versioncheck}}</noinclude> |
| − | The executable Slicer application ''Slicer-Superbuild/Slicer-build/Slicer'' (or Slicer.exe) is the [[Documentation/{{documentation/version}}/Developers/Launcher|launcher]] of the real application binary ''Slicer-Superbuild/Slicer-build/bin/SlicerApp-real''.
| |
| | | | |
| − | ==Linux==
| + | {{documentation/banner |
| − | ===Analyze a segmentation fault===
| + | | text = [https://slicer.readthedocs.io/en/latest/developer_guide/debugging/index.html This page has been moved to read-the-docs.] |
| − | $ ulimit -c unlimited
| + | | background-color = 8FBC8F }} |
| − | $ ./Slicer
| |
| − | ... make it crash
| |
| − | $ ./Slicer --gdb ./bin/SlicerApp-real
| |
| − | (gdb) core core
| |
| − | (gdb) backtrace
| |
| − | ...
| |
| − | | |
| − | ===GDB debug with launch arguments===
| |
| − | The Slicer app launcher provides options to start other programs with the Slicer environment settings.
| |
| − | | |
| − | *<code>--launch <executable> [<parameters>]</code>: executes an arbitrary program. For example, <code>Slicer --launch /usr/bin/gnome-terminal</code> starts gnome-terminal (then run GDB directly on SlicerQT-real)
| |
| − | *<code>--gdb</code>: runs GDB then executes SlicerQT-real from within the debugger environment.
| |
| − | | |
| − | ===GDB debug by attaching to running process [RECOMMENDED] ===
| |
| − | | |
| − | 1) Running Slicer with the following command line argument will allow you to easily obtain the associated PID:
| |
| − | | |
| − | $ ./Slicer --attach-process
| |
| − | | |
| − | This will bring up a window with the <code>PID</code> before loading any modules, which is also helpful for debugging the loading process.
| |
| − | | |
| − | 2) Then, you can attach the process to <code>gdb</code> using the following command:
| |
| − | | |
| − | $ gdb --pid $PIDABOVE
| |
| − | | |
| − | 3) Finally type the following gdb command
| |
| − | | |
| − | (gdb) continue
| |
| − | | |
| − | If not using the <code>--attach-process</code>, the <code>PID</code> could be obtain using the following command:
| |
| − | | |
| − | $ ps -Afww | grep SlicerApp-real
| |
| − | | |
| − | | |
| − | ==== Ubuntu 10.10 and above - How to enable ptracing ====
| |
| − | In Ubuntu 10.10, Ubuntu introduced a patch to disallow ptracing of non-child processes by non-root users -ie. only a process which is a parent of another process can ptrace it for normal users.
| |
| − | You can temporarily disable this restriction by:
| |
| − | $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope | |
| − | To permanently allow it to edit /etc/sysctl.d/10-ptrace.conf and change the line:
| |
| − | *<code>kernel.yama.ptrace_scope = 1</code>
| |
| − | to read:
| |
| − | *<code>kernel.yama.ptrace_scope = 0</code>
| |
| − | | |
| − | See http://askubuntu.com/questions/41629/after-upgrade-gdb-wont-attach-to-process
| |
| − | | |
| − | ===GDB debug by using exec-wrapper=== | |
| − | An alternative approach is to use a wrapper script to emulate the functionality of the app launcher. This will allow you to use gdb or a gdb-controlling program such as an IDE, in order to interactively debug directly from GDB without attaching.
| |
| − | | |
| − | The general idea of the wrapper is to set all of the appropriate environment variables as they would be set by the app launcher. From SlicerLauncherSettings:
| |
| − | *[LibraryPath] contents should be in LD_LIBRARY_PATH
| |
| − | *[Paths] contents should be in PATH
| |
| − | *[EnvironmentVariables] should each be set
| |
| − | | |
| − | See [[Slicer4:Example_Wrapper_Script|this example script]]
| |
| − | | |
| − | Now, start gdb and do the following:
| |
| − | <pre>
| |
| − | (gdb) set exec-wrapper ./WrapSlicer4
| |
| − | (gdb) exec-file ./bin/SlicerQT-real
| |
| − | (gdb) run
| |
| − | </pre>
| |
| − | | |
| − | Since VTK and ITK include many multithreaded filters, by default you will see lots of messages like the following from gdb during rendering and processing:
| |
| − | [New Thread 0x7fff8378f700 (LWP 20510)]
| |
| − | [Thread 0x7fff8b0aa700 (LWP 20506) exited]
| |
| − | | |
| − | These can be turned off with this command:
| |
| − | set print thread-events off
| |
| − | | |
| − | ===GDB debug in CodeLite IDE===
| |
| − | | |
| − | [[{{FULLPAGENAME}}/CodeLite|Linux debugging with CodeLite IDE]]
| |
| − | | |
| − | == Windows ==
| |
| − | | |
| − | For VisualStudio it's also possible to run the IDE with the correct environment to debug slicer.
| |
| − | | |
| − | The launcher gets configured with a special --VisualStudio option for this purpose.
| |
| − | | |
| − | When Visual Studio is open, you can debug it by setting the project SlicerApp-real as current and run Debug (F5).
| |
| − | | |
| − | Note that because CMake re-creates the solution file from within the build process, visual studio will sometimes need to stop and reload the project, requiring manual button pressing on your part. To avoid this, you can use a script to kick off the build and then re-start the IDE.
| |
| − | | |
| − | If you use cygwin, you can create simple shell scripts, for example in /usr/local/bin, which these several steps at once when run from the Slicer4-superbuild directory:
| |
| − | | |
| − | * ''s4build'' (slicer4 build)
| |
| − | (cd Slicer-build; cmake.exe -VV --debug-output . && ./Slicer.exe --VisualStudio Slicer.sln /out buildlog.txt /build)
| |
| − | (cd Slicer-build; ./Slicer.exe --VisualStudio Slicer.sln)
| |
| − | * ''s4sbuild'' (slicer4 super build)
| |
| − | (cmake.exe -VV --debug-output . && ./Slicer-build/Slicer.exe --VisualStudio Slicer.sln /out buildlog.txt /build)
| |
| − | (cd Slicer-build; ./Slicer.exe --VisualStudio Slicer.sln)
| |
| − | | |
| − | The ''s4build'' command re-runs cmake and then runs the build of Slicer only. When this completes, it launches visual studio with slicer loaded for debugging.
| |
| − | | |
| − | ''s4sbuild'' is similar, but it runs the superbuild process so that all the dependency libraries are updated. This takes longer, but is sometimes needed when there has been a change to CTK or other tools.
| |
| − | | |
| − | Note the buildlog.txt files for checking if anything went wrong.
| |
| − | | |
| − | == Mac (Xcode) ==
| |
| − | | |
| − | [[image:Xcode-scheme-Screen Shot 2012-10-05 at 10.13.30 AM.png|thumb|right|200px]]
| |
| − | | |
| − | As of slicer 4.2, we do not support building using Xcode, however if you build slicer using traditional unix Makefiles you can still debug using the powerful source debugging features of Xcode. You may need to set up a dummy project in Xcode just to enable some of the menu options.
| |
| − | | |
| − | You can use the Attach to Process option in the Xcode Product menu for debugging. This will allow you to get browsable stack traces for crashes.
| |
| − | | |
| − | To set a breakpoint in code that is not crashing, you can set it via the command line interface. For the lldb debugger, first attach to the process and break the program. Then at the (lldb) prompt, stop at a method as follows:
| |
| − | | |
| − | breakpoint set -M vtkMRMLScene::Clear
| |
| − | | |
| − | then you can single step and/or set other breakpoints in that file.
| |
| − | | |
| − | | |
| − | To debug startup issues you can set up a 'Scheme' and select the Slicer.app in your Slicer-build directory (see screen shot). You can set up multiple schemes with different command line arguments and executables (for example to debug tests).
| |
| − | | |
| − | Also on the mac, the [http://en.wikipedia.org/wiki/Instruments_%28application%29 Instruments] tool is very useful for profiling.
| |
| − | | |
| − | ==Debugging a Test==
| |
| − | Once VisualStudio is open with the Slicer environment loaded, it is possible to run and debug tests.
| |
| − | To run all tests, build the ''RUN_TESTS'' project.
| |
| − | #To debug a test, find its project:
| |
| − | ##Libs/MRML/Core tests are in the ''MRMLCoreCxxTests'' project
| |
| − | ##CLI tests are in ''CLI_NAMETest'' project (e.g. ThresholdScalarVolumeTest)
| |
| − | ##Loadable module tests are in ''qSlicerLOADABLE_NAMECxxTests'' project (e.g. qSlicerVolumeRenderingCxxTests)
| |
| − | ##Module logic tests are in ''MODULE_NAMELogicCxxTests'' project (e.g. VolumeRenderingLogicCxxTests)
| |
| − | ##Module widgets tests are in ''MODULE_NAMEWidgetsCxxTests'' project (e.g. VolumesWidgetsCxxTests)
| |
| − | #Go to the project debugging properties (right click -> Properties, then Configuration Properties/Debugging)
| |
| − | #In ''Command Arguments'', type the name of the test (e.g. <code>vtkMRMLSceneImportTest</code> for project MRMLCoreCxxTests)
| |
| − | # If the test takes argument(s), enter the argument(s) after the test name in ''Command Arguments'' (e.g. <code>vtkMRMLSceneImportTest C:\Path\To\Slicer4\Libs\MRML\Core\Testing\vol_and_cube.mrml</code>)
| |
| − | ## You can see what arguments are passed by the dashboards by looking at the test details in [http://slicer.cdash.org/index.php?project=Slicer4 CDash].
| |
| − | ## Most VTK and Qt tests support the <code>-I</code> argument, it allows the test to be run in "interactive" mode. It doesn't exit at the end of the test.
| |
| − | # Make the project ''Set As StartUp Project''
| |
| − | # ''Start Debugging (F5)''
| |
