Difference between revisions of "Development/Tutorials/Debugging"

Jump to: navigation, search
 
(17 intermediate revisions by 7 users not shown)
Line 1: Line 1:
There are several ways to debug an existing program:
+
 
* you know your program and insert kDebug statements to trace the course of the program
+
Debugging KDE applications can be done on different levels. Most applications "talk" invisibly through debug statements while they are running. Looking at this information mostly gives you enough info to find out what went wrong. For further details, read the dedicated article about [[Development/Tutorials/Debugging/Using Error Messages|error messages]].
* you use [[KDbg]] from our [[tools]]
+
 
* you use [[add_trace]]
+
On a different level we have post-mortem debugging. This is used ''after'' an application died, probably because of a programming error. The drkonqi dialog allows you to create a '''backtrace''', and possibly find out where it went wrong.
This program lets you modify your sourcecode so that an information is printed everytime the program enters a function. This is good if you do not know in which function your problem occurs.
+
 
 +
There are debuggers like gdb which can do a lot more than just find out where it went wrong. You should read the man page of gdb to find out more, and possibly download 'kdbg', 'ddd', or 'inspire' which make gdb a lot simpler to use. Read [[Development/Tutorials/Debugging/Debugging with GDB|Debugging with GDB]] for a detailed tutorial.
 +
 
 +
== Related Pages ==
 +
*[[Development/Tutorials/Debugging/Shared Memory Usage in KDE|Shared Memory Usage in KDE]]
 +
*[[Development/Tutorials/Debugging/Using Error Messages|Using error messages (kDebug)]]
 +
*[[Development/Tutorials/Debugging/Debugging symbols|Debugging symbols]]
 +
*[[Development/Tutorials/Debugging/Debugging with GDB|Debugging with GDB]]
 +
*[[Development/Tutorials/Debugging/Debugging IOSlaves|Debugging IOSlaves]]
 +
*[[Development/Tutorials/Debugging/Debugging on MS Windows|Debugging on MS Windows]]
 +
*[[Development/FAQs/Debugging_FAQ|Debugging FAQ]]
 +
*[[Development/Tutorials/Debugging/How to create useful crash reports|How to create useful crash reports]]
 +
*For information on debugging tool such as valgrind and [http://kdbg.org/ KDbg], visit the [[../../Tools|tools pages]].
 +
*[[Development/Tutorials/Debugging/Phonon|Debugging Phonon]]
 +
 
 +
[[Category:Programming]]

Latest revision as of 19:54, 12 July 2012

Debugging KDE applications can be done on different levels. Most applications "talk" invisibly through debug statements while they are running. Looking at this information mostly gives you enough info to find out what went wrong. For further details, read the dedicated article about error messages.

On a different level we have post-mortem debugging. This is used after an application died, probably because of a programming error. The drkonqi dialog allows you to create a backtrace, and possibly find out where it went wrong.

There are debuggers like gdb which can do a lot more than just find out where it went wrong. You should read the man page of gdb to find out more, and possibly download 'kdbg', 'ddd', or 'inspire' which make gdb a lot simpler to use. Read Debugging with GDB for a detailed tutorial.

[edit] Related Pages


This page was last modified on 12 July 2012, at 19:54. This page has been accessed 21,322 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal