Difference between revisions of "Development/FAQs/Debugging FAQ"

Jump to: navigation, search
(Marked this version for translation)
(Replaced content with "{{Moved To Community | Guidelines_and_HOWTOs/Debugging }}")
 
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>
+

Latest revision as of 09:07, 5 August 2016

This page is now on the community wiki.


This page was last modified on 5 August 2016, at 09:07. Content is available under Creative Commons License SA 4.0 unless otherwise noted.