Guidelines and HOWTOs/Debugging: Difference between revisions

From KDE Community Wiki
No edit summary
No edit summary
Line 6: Line 6:
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|Debugging with GDB]] for a detailed tutorial.
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|Debugging with GDB]] for a detailed tutorial.


== Related Pages ==
== Tools ==
; Valgrind
: [[/Valgrind|Valgrind]] helps to find memory leaks and uninitialized memory blocks. Additional features are a profiler and more. Valgrind is one of the most important development tools!
 
; The GNU Project Debugger (GDB)
: [http://sources.redhat.com/gdb/ GDB] helps in debugging source code. As GDB evolved over time it is recommended to use version 6.x. Graphical frontends are available (see below). See also the debugging tutorial [[//Debugging with GDB|Debugging with GDB]].
 
; KDbg and DDD
: [http://www.kdbg.org/ KDbg] and [http://www.gnu.org/software/ddd/ DDD] are graphical user interfaces to GDB, which are able to set breakpoints, step through the code etc.
 
; MS Windows tools (Process Explorer, Console, WinDbg, DebugView...)
: More info on the [[Windows|KDE on Windows page]].
 
== Related Pages (Misc) ==
*[[/Shared Memory Usage in KDE|Shared Memory Usage in KDE]]
*[[/Shared Memory Usage in KDE|Shared Memory Usage in KDE]]
*[[/Using Error Messages|Using error messages (kDebug)]]
*[[/Using Error Messages|Using error messages (kDebug)]]

Revision as of 19:03, 1 June 2016

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.

Tools

Valgrind
Valgrind helps to find memory leaks and uninitialized memory blocks. Additional features are a profiler and more. Valgrind is one of the most important development tools!
The GNU Project Debugger (GDB)
GDB helps in debugging source code. As GDB evolved over time it is recommended to use version 6.x. Graphical frontends are available (see below). See also the debugging tutorial [with GDB|Debugging with GDB].
KDbg and DDD
KDbg and DDD are graphical user interfaces to GDB, which are able to set breakpoints, step through the code etc.
MS Windows tools (Process Explorer, Console, WinDbg, DebugView...)
More info on the KDE on Windows page.

Related Pages (Misc)