|
|
| Line 1: |
Line 1: |
| <languages />
| | {{Moved To Community | Guidelines_and_HOWTOs/Debugging }} |
| <translate>
| |
| ==General== <!--T:1-->
| |
| | |
| ===How do I avoid Dr Konqi?=== <!--T:2-->
| |
| | |
| <!--T:3-->
| |
| You must set the environment variable KDE_DEBUG (to 1 or whatever you want in fact).
| |
| | |
| <!--T:4-->
| |
| To get Dr Konqi back, unset the KDE_DEBUG environment variable.
| |
| | |
| <!--T:5-->
| |
| Example:<br />
| |
| *To avoid Dr Konqi:
| |
| ::<syntaxhighlight lang="bash">export KDE_DEBUG=1</syntaxhighlight>
| |
| *To see Dr Konqi:
| |
| ::<syntaxhighlight lang="bash">unset KDE_DEBUG</syntaxhighlight>
| |
| | |
| ===How do I switch Dr Konqi to developer mode?=== <!--T:6-->
| |
| | |
| <!--T:7-->
| |
| Edit file $KDEHOME/share/config/drkonqirc and add the following:
| |
| <syntaxhighlight lang="ini">
| |
| [drkonqi]
| |
| ConfigName=developer
| |
| </syntaxhighlight>
| |
| | |
| ===What is a core file? How do I get a core file?=== <!--T:8-->
| |
| | |
| <!--T:9-->
| |
| A core file is an image of the memory when your application crashed. Using the core file, you can know which variables were set and where your application crashed.
| |
| | |
| <!--T:10-->
| |
| Some distributions disable the generation of core files. To re-enable them, use <code>ulimit -c unlimited</code>.
| |
| | |
| <!--T:11-->
| |
| Once you have a core file for a crash, you can examine it with gdb appname core . This will open gdb on the core file for the given application. Once at the gdb prompt, the most useful command is <code>bt</code> which generates a backtrace of the crash.
| |
| For more information about how to use gdb, see [[Special:myLanguage/Development/Tutorials/Debugging/Debugging_with_GDB|this page]]
| |
| | |
| ===What tools are available to debug my application?=== <!--T:12-->
| |
| | |
| <!--T:13-->
| |
| *kDebug() (kdDebug() in KDE3) calls are a simple but efficient way to debug an application.
| |
| *gdb, the GNU debugger, is the quickest way to execute step-by-step and investigate variables (recommended versions are gdb >= 6.x)
| |
| *Valgrind
| |
| *kdbg is a nice graphical frontend to gdb with a KDE GUI. It has support for many Qt types (including QString).
| |
| *Memory leak tracer : See kdesdk/kmtrace. The README explains it all.
| |
| *qdbus and dbusviewer from Qt allow to browse DBus interfaces and to easily make DBus calls.
| |
| | |
| <!--T:14-->
| |
| Check [[Special:myLanguage/Development/Tools|this page]] and kdesdk, there are a bunch of useful scripts there.
| |
| | |
| ===How do I print a QString in gdb?=== <!--T:15-->
| |
| | |
| <!--T:16-->
| |
| Check out kdesdk, and add this line to your ~/.gdbinit :
| |
| {{Input|1=source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb}} | |
| Then in gdb you can do <code>printqstring myqstring</code> to see its contents.
| |
| For instance, <code>QString myqstring = QString::fromLatin1("contents");</code> can be examined using
| |
| | |
| <!--T:17-->
| |
| {{Input|1=
| |
| (gdb) printqstring myqstring
| |
| $1 = "content"}}
| |
| | |
| <!--T:18-->
| |
| See the <tt>kde-devel-gdb</tt> file for the other macros it defines.
| |
| | |
| ===I have no symbol when I debug an app that uses kpart, what should I do?=== <!--T:19-->
| |
| | |
| <!--T:20-->
| |
| You must stop just after the main to load the debugging symbols of the shared library. After that, you can debug normally.
| |
| One can go as far as creating a gdb macro, to stop right after the part was loaded. For kword, by example, I use:
| |
| {{Input|1=
| |
| define startkword
| |
| break main
| |
| run
| |
| break 'KoDocument::KoDocument(int, QWidget *, char const *,
| |
| QObject *, char const *, bool)' cont}}
| |
| | |
| ===How do I debug an ioslave?=== <!--T:21-->
| |
| | |
| <!--T:22-->
| |
| See [[Development/Tutorials/Debugging/Debugging IOSlaves|debugging ioslaves]]
| |
| | |
| === Why isn't my signal and slot connection working? === <!--T:23-->
| |
| | |
| <!--T:24-->
| |
| Here are some steps that you can use to troubleshoot why your signal/slot connection is not working (your slot does not get called for some reason).
| |
| | |
| <!--T:25-->
| |
| 1) Verify that the connect() doesn't print a warning to the console at runtime.
| |
| | |
| <!--T:26-->
| |
| If it does, check that you wrote Q_OBJECT, that the parameter names are not in the connect, that the parameter types are compatible, and that the slot is defined, and that the moc was compiled.
| |
| | |
| <!--T:27-->
| |
| 1b) Or you can just check to see what connect() returns as a bool. Although this won't give you the error message.
| |
| 2) Verify that the signal is indeed emitted
| |
| 3) Verify that the receiver isn't already deleted at that time
| |
| 4) Verify that emitter->signalsBlocked() returns false
| |
| | |
| ===Is there a preferred way to print debug output on stderr?=== <!--T:29-->
| |
| | |
| <!--T:40-->
| |
| Yes; see [[Special:myLanguage/Development/Tutorials/Debugging/Using_Error_Messages|this tutorial]].
| |
| | |
| <!--T:39-->
| |
| [[Category:FAQs]]
| |
| [[Category:Programming]]
| |
| </translate>
| |
