[ fromfile: debugging.xml id: gdb ]

Imagine you are running a program and, for some mysterious reason, it crashes.

[lazarus] app> ./playlistmgr
Segmentation fault
[lazarus] app>

When your application aborts, or crashes, it is helpful to know (as quickly as possible) exactly where it happened. You can use gdb to locate the trouble spot quickly and easily. Following is a short example of a command-line gdb session.

[lazarus] app> gdb playlistmgr
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb)  r  []
Starting program: ftgui/app/playlistmgr
[Thread debugging using libthread_db enabled]
[New Thread -1227622176 (LWP 17021)]
Qt: gdb: -nograb added to command-line options.
         Use the -dograb option to enforce grabbing.
This is a debug message

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1227622176 (LWP 17021)]
0xb7f03320 in FormDialog::createActions (this=0x80ae2a0) at formdialog.cpp:53
53          delete m_OkAction;
(gdb)

gdb shows you not only the filename, and line number, but also the corresponding line in the source code. However, you still might want to get some context for this error. The command list shows you the surrounding source code for the current file:

(gdb) list
51      void FormDialog::createActions() {
52
53          delete m_OkAction;
54          delete m_CancelAction;
55          m_OkAction = new OkAction(m_Model, m_View);
56          m_CancelAction = new CancelAction(m_Model, m_View);
57          QHBoxLayout *buttons = new QHBoxLayout(0);
(gdb)

The command where shows you the stack trace, or how you got that error spot.

(gdb) where
#0  0xb7f03320 in FormDialog::createActions (this=0x80ae2a0) at formdialog.cpp:53
#1  0xb7f03058 in FormDialog::setModel (this=0x80ae2a0, fmodel=0x80c80d0)
    at formdialog.cpp:34
#2  0x080664bd in SettingsDialog (this=0x80ae2a0, parent=0x0) at settingsdialog.cpp:14
#3  0x0805f313 in MainWindow (this=0xbfffdec8) at mainwindow.cpp:42
#4  0x08066f14 in Controller (this=0xbfffdec0, argc=1, argv=0xbfffdfe4) at controller.cpp:25
#5  0x0805a8a4 in main (argc=1, argv=0xbfffdfe4) at main.cpp:7
(gdb)

Most open source IDEs such as Eclipse and QtCreator use gdb under the hood. They each offer a user interface that makes certain features easier to learn and use. ccdebug is written in Qt and designed specifically for debugging Qt applications, including QString support.

Viewing QStrings Inside the Debugger

QStrings are hard to see inside some debuggers because they are indirect pointers to Unicode data. The debugger needs to know extra things about a QString to display it properly. If you use an IDE with Qt integration installed, you should be able to see QStrings in your debugger. If you are using QtCreator and can't see them, go to the Qt settings and check if the debugging helpers can be built for the version of Qt you are using. If you are using command-line gdb, you can download kde-devel-gdb, a collection of Qt helper macros from the KDE subversion repository, and put the following lines in your ~/.gdbinit file. source /path/to/kde/kde-devel-gdb define pqs printq4string $arg0 end the pqs macro should enable you to print QStrings while you are debugging.

	.gdbinit
	You can use the file .gdbinit to automate the loading of a particular executable, the setting of breakpoints, and starting up your debugging session. Whenever you find yourself running gdb and entering the same commands repeatedly, try adding that sequence of commands to the .gdbinit in the same directory as your project.