comparison Sphinx/source/faq/crash.rst @ 239:a162fa200a13

crash
author Sebastien Jodogne <s.jodogne@gmail.com>
date Sat, 27 Apr 2019 15:52:49 +0200
parents
children ea82efa0885a
comparison
equal deleted inserted replaced
238:a363714813b2 239:a162fa200a13
1 .. _crash:
2
3 Crash analysis
4 ==============
5
6 If you experience a crash within Orthanc (or one of its plugins), that
7 the troubleshooting sections (cf. :ref:`here <troubleshooting>` and
8 :ref:`here <dicom>`) do not help, and that you can't provide a robust
9 way to reproduce your issue by third-party developers, you'll have to
10 analyze the backtrace of Orthanc.
11
12
13 .. _segfault-plugin:
14
15 Generating a segmentation fault for test purpose
16 ------------------------------------------------
17
18 .. highlight:: cpp
19
20 Here is the source code of a minimal C++ :ref:`plugin
21 <creating-plugins>` that can be used to simulate a segmentation fault
22 within Orthanc::
23
24 #include <orthanc/OrthancCPlugin.h>
25
26 extern "C"
27 {
28 int32_t OrthancPluginInitialize(OrthancPluginContext* context)
29 {
30 // Let's trigger a segmentation fault by writing to NULL
31 intptr_t *p = NULL;
32 *p = 42;
33 return OrthancPluginErrorCode_Success;
34 }
35
36 void OrthancPluginFinalize()
37 {
38 }
39
40 const char* OrthancPluginGetName()
41 {
42 return "crash";
43 }
44
45 const char* OrthancPluginGetVersion()
46 {
47 return "0.0";
48 }
49 }
50
51 As soon as Orthanc will try and load this plugin, it will crash. This
52 gives you the opportunity to learn how to debug Orthanc on your very
53 specific platform.
54
55
56 Any system
57 ----------
58
59 First :ref:`compile Orthanc by yourself <compiling>`, in debug mode by
60 setting ``-DCMAKE_BUILD_TYPE=Debug`` when invoking CMake.
61
62 Then, learn how to use the debugger that is best suited to your
63 platform (e.g. Microsoft Visual Studio, gdb or Xcode).
64
65
66 GNU/Linux system using gdb
67 --------------------------
68
69 .. highlight:: bash
70
71 The Orthanc project provides precompiled debug binaries that can be
72 run on almost any recent GNU/Linux system. This allows to generate a
73 backtrace (the famous "core dumped" message) that can be analyzed by
74 any developer of Orthanc. Assuming that the :ref:`plugin above
75 <segfault-plugin>` is available as the ``crash.cpp`` file, here is a
76 sample debug session::
77
78 $ wget http://orthanc.osimis.io/lsb/orthanc-debug/releases/1.5.6/Orthanc
79 $ chmod +x ./Orthanc
80 $ gcc -fPIC -shared ./crash.cpp -I ~/orthanc/Plugins/Include -o crash.so
81 $ ulimit -c unlimited
82 $ echo '{ "Plugins" : ["crash.so"] }' > Configuration.json
83 $ rm -f core ; ./Orthanc Configuration.json
84 W0427 15:43:24.215783 main.cpp:1436] Orthanc version: 1.5.6
85 W0427 15:43:24.215910 main.cpp:1279] Performance warning: Non-release build, runtime debug assertions are turned on
86 W0427 15:43:24.217585 OrthancConfiguration.cpp:61] Reading the configuration from: "Configuration.json"
87 W0427 15:43:24.254733 main.cpp:700] Loading plugin(s) from: crash.so
88 W0427 15:43:24.254866 PluginsManager.cpp:269] Registering plugin 'crash' (version 0.0)
89 Segmentation fault (core dumped)
90
91
92 .. highlight:: text
93
94 This session creates a file called ``core`` in the current working
95 directory. You can analyze it by running ``gdb`` as follows::
96
97 $ gdb -c ./core ./Orthanc
98 (gdb) bt
99 #0 0x00007f7b1aa3d739 in OrthancPluginInitialize () from crash.so
100 #1 0x00000000008632f0 in Orthanc::CallInitialize (plugin=..., context=...)
101 at /home/jodogne/BuildBotWorker/Orthanc_1_5_6_-_LSB_Debug/build/Plugins/Engine/PluginsManager.cpp:98
102 #2 0x0000000000864496 in Orthanc::PluginsManager::RegisterPlugin (this=0x4314f90, path="crash.so")
103 at /home/jodogne/BuildBotWorker/Orthanc_1_5_6_-_LSB_Debug/build/Plugins/Engine/PluginsManager.cpp:272
104 ...
105
106 If you are unable to analyze such a backtrace by yourself, feel free
107 to post your ``core`` file on the `Orthanc forum
108 <https://groups.google.com/forum/#!forum/orthanc-users>`__.
109
110 **Important:** The Orthanc developers will only be able to analyze the
111 ``core`` files generated by our own precompiled binaries!
112
113 NB: In the future, debug binaries will be provided for the official
114 plugins (work in progress).
115
116
117 Docker
118 ------
119
120 To be written.