Development/Tutorials/Debugging/Debugging symbols and Development/Tutorials/Debugging: Difference between pages

Revision as of 01:39, 19 March 2011

Development/Tutorials/Debugging

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.

Related Pages

Shared Memory Usage in KDE
Using error messages (kDebug)
Debugging symbols
Debugging with GDB
Debugging IOSlaves
Debugging on MS Windows
Debugging FAQ
How to create useful crash reports
For information on debugging tool such as valgrind and KDbg, visit the tools pages.
Debugging Phonon

@@ Line 1: / Line 1: @@
-Debugging symbols allow you to debug your application better. Debugging symbols are added to your binary by the compiler. You have to decide during the cmake step if you want debugging symbols or not. To compile your application with debugging symbols, use
+{{Template:I18n/Language_Navigation_Bar|Development/Tutorials/Debugging}}
- cmake . -DCMAKE_BUILD_TYPE=debugfull
-to compile it without debugging symbols, use
- cmake . -DCMAKE_BUILD_TYPE=release
-Depending on your decision, output generated with the command kDebug will also be (debugfull) or not be (release) added to your application.
-As an example, let's start with a hello world application.
+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]].
-'''main.cpp'''
+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.
-<pre>
-#include <KApplication>
-#include <KAboutData>
-#include <KCmdLineArgs>
-#include <KMessageBox>
-int main (int argc, char *argv[])
-{
-    KAboutData aboutData(
-                         // The program name used internally.
-                         "tutorial1",
-                         // The message catalog name
-                         // If null, program name is used instead.
-,
-                         // A displayable program name string.
-                         ki18n("Tutorial 1"),
-                         // The program version string.
-                         "1.0",
-                         // Short description of what the app does.
-                         ki18n("Displays a KMessageBox popup"),
-                         // The license this code is released under
-                         KAboutData::License_GPL,
-                         // Copyright Statement
-                         ki18n("(c) 2007"),
-                         // Optional text shown in the About box.
-                         // Can contain any information desired.
-                         ki18n("Some text..."),
-                         // The program homepage string.
-                         "http://tutorial.com/",
-                         // The bug report email address
-                         "[email protected].org");
-    KCmdLineArgs::init( argc, argv, &aboutData );
+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.
-    KApplication app;
-    KGuiItem yesButton( i18n( "Hello" ), QString(),
+== Related Pages ==
-                        i18n( "This is a tooltip" ),
+*[[Development/Tutorials/Debugging/Shared Memory Usage in KDE|Shared Memory Usage in KDE]]
-                        i18n( "This is a WhatsThis help text." ) );
+*[[Development/Tutorials/Debugging/Using Error Messages|Using error messages (kDebug)]]
-    KMessageBox::questionYesNo( 0, i18n( "Hello World" ),
+*[[Development/Tutorials/Debugging/Debugging symbols|Debugging symbols]]
-                                i18n( "Hello" ), yesButton );
+*[[Development/Tutorials/Debugging/Debugging with GDB|Debugging with GDB]]
-    return 0;
+*[[Development/Tutorials/Debugging/Debugging IOSlaves|Debugging IOSlaves]]
-}
+*[[Development/Tutorials/Debugging/Debugging on MS Windows|Debugging on MS Windows]]
-</pre>
+*[[Development/FAQs/Debugging_FAQ|Debugging FAQ]]
-'''CMakeLists.txt'''
+*[[Development/Tutorials/Debugging/How to create useful crash reports|How to create useful crash reports]]
-<pre>
+*For information on debugging tool such as valgrind and [http://kdbg.org/ KDbg], visit the [[../../Tools|tools pages]].
-project (tutorial1)
+*[[Development/Tutorials/Debugging/Phonon|Debugging Phonon]]
-find_package(KDE4 REQUIRED)
-include (KDE4Defaults)
+[[Category:Programming]]
-include_directories(${KDE4_INCLUDES})
-set(tutorial1_SRCS main.cpp)
-kde4_add_executable(tutorial1 ${tutorial1_SRCS})
-target_link_libraries(tutorial1 ${KDE4_KDEUI_LIBS})
-install(TARGETS tutorial1  ${INSTALL_TARGETS_DEFAULT_ARGS})
-</pre>
-Now let's compile this without debugging symbols:
- cmake . -DCMAKE_BUILD_TYPE=release