Development/Tutorials/Debugging/Debugging with GDB

Revision as of 00:05, 31 January 2012 by Dvratil(Talk | contribs)(Replace information about obsoleted gdb printers from KDESDK by links and instructions to working and maintained printers from KDevelop.)

This is a short tutorial on debugging KDE applications. Throughout this
tutorial I will use "kedit" as an example application.

Debugging with GDB

The recommended version of gdb to use is version 4.95 or higher; older
versions have problems generating proper backtraces.

There are three ways to debug an application with gdb:

You can start the application from within gdb.

You can attach gdb to an already running application.

You can run gdb after an application has crashed using a core file.

Starting applications from within gdb

To start an application with gdb you can start gdb as follows:

> gdb kedit
GNU gdb 4.95.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb)

You can now set the command line arguments that you want to pass to kedit with
the gdb command "set args":

(gdb) set args myfile.txt
(gdb)

gdb has loaded the kedit executable on startup but it hasn't loaded any of
the libraries yet. This means that you can't set any breakpoints in the
libraries yet. The easiest way to do that is to set a breakpoint in the
first line of main and then start the program:

You can now set breakpoints everywhere. For example lets set a breakpoint
in the KApplication constructor. Unfortunately, gdb is not very good in
handling C++ names, so it is not really possible to specify the constructor
directly after the break command. Instead we look up a line of source
code where we want to place the breakpoint. An external editor is of great
use at this point. With the list command we can select the source file we
are interested in and verify that we have found the correct source line:

Important: many applications use "KUniqueApplication" to ensure that only one instance can exist at a given time in a given KDE session. This is the case for kwin, kontact, konsole, plasma, etc. To debug those applications, attach to them while they're running (see next session) or use set args --nofork

Attaching gdb to already running applications

Sometimes it is not practical to start an application from within gdb.
E.g. in those cases where you didn't know the application was about to
crash :-) When you get the friendly DrKonqi dialog informing you about
a crash you are just in time to start your debugger.

First lets attach gdb to an application that hasn't crashed (yet).

You start with finding the process of the application with e.g. ps -aux:

From this you learn that kedit has process id 21570. Now you can start gdb as
follows:

> gdb kedit 21570
GNU gdb 4.95.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
/home1/bastian/21570: No such file or directory.
Attaching to program: /ext/kde2.0/bin/kedit, Pid 21570
Reading symbols from /ext/kde2.0/lib/kedit.so.0...done.
Loaded symbols for /ext/kde2.0/lib/kedit.so.0
...
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_compat.so.2...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
0x40c3d88e in __select () from /lib/libc.so.6
(gdb)

You will usually end up in the middle of a select() call from the event-loop.
This is the place where a KDE application spends most of its time, waiting
for things to happen.

Debugging core files with GDB

Debugging process requires much memory. If you have to inspect crash, you can debug core files. It's much faster and requires less memory. First limit the maximum size of core files and run the application:

ulimit -c 100000
kedit --nocrashhandler

Do not forget to use --nocrashhandler option. Core file would be created if the application crashed, so you can use gdb with created core file:

gdb kedit ./core-file #in my system it is core.PID

Improving your gdb experience for KDE/Qt applications

Since version 7 GDB supports Python scripting for pretty printers. There are such scripts for basic Qt types (QString, QList, QMap, QHash, QDateTime and many others) in KDevelop git repository. Download the scripts and add following lines to your ~/.gdbinit to load the scripts automatically as start: