File: o-gdb.rst.txt

package info (click to toggle)
cyrus-imapd 3.6.1-4%2Bdeb12u3
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 80,688 kB
  • sloc: ansic: 255,928; perl: 97,730; javascript: 9,266; sh: 5,537; yacc: 2,651; cpp: 2,128; makefile: 2,099; lex: 660; xml: 621; python: 388; awk: 303; asm: 262
file content (37 lines) | stat: -rw-r--r-- 1,362 bytes parent folder | download | duplicates (16)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
.. _faqs-o-gdb:

How to run gdb on Cyrus components
----------------------------------

.. sidebar:: What is a service daemon?

    A service daemon is any program based around master/service.c. This includes
    imapd, lmtpd (and some others), but does *not* include the command line
    tools.

An easy way to debug something in a service daemon is to write a
:ref:`Cassandane test <developer-testing>` that tries to reproduce the
bug. Cassandane has a ``[gdb]`` section in cassandane.ini which allows for
starting service daemons in a debugger.

The cassandane.ini.example in the cassandane repository contains examples and
instructions.

For programs that aren't service daemons, there are two options:

If they are installed, run them with gdb. You might need to use ``sudo``
depending on permissions. If they haven't been installed (and you're in the
source/build tree), you need to run gdb from ``libtool`` in order for everything
to work.

For example, if you wanted to debug cyr_virusscan:

.. code-block:: bash

    $ libtool --mode=execute gdb imap/cyr_virusscan

Command line arguments for a tool you're debugging, must be given to gdb before
you run. Use something like `set args [ ... ]
<https://sourceware.org/gdb/current/onlinedocs/gdb/Arguments.html#Arguments>`_.

`More information on gdb <http://sourceware.org/gdb/current/onlinedocs/gdb/>`_.