DDD is a graphical front-end for GDB and other command-line debuggers.
This is the First Edition of Debugging with DDD, 2000-01-03, for DDD Version 3.2.
Copyright © 2000 Universität Passau
Lehrstuhl für Software-Systeme
Innstraße 33
D-94032 Passau
GERMANY
Distributed by
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307
USA
DDD and this manual are available via the DDD WWW page.
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the sections entitled "Copying" and "GNU General Public License" (see License) are included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation.
Send questions, comments, suggestions, etc. to ddd@gnu.org.
Send bug reports to bug-ddd@gnu.org.
The purpose of a debugger such as DDD is to allow you to see what is going on "inside" another program while it executes--or what another program was doing at the moment it crashed.
DDD can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:
Technically speaking, DDD is a front-end to a command-line debugger (called inferior debugger, because it lies at the layer beneath DDD). DDD supports the following inferior debuggers:
See Choosing an Inferior Debugger, for choosing the appropriate inferior debugger. See Sample Session, for getting a first impression of DDD.
This manual comes in several formats:
info program, or from
DDD via Help => DDD Manual.
The DDD source distribution
ddd-3.2.tar.gz contains this manual as
pre-formatted info files; you can also download them from
the DDD WWW page.
The DDD source distribution
ddd-3.2.tar.gz contains this manual as
pre-formatted PostScript file; you can also download it from
the DDD WWW page.
The DDD source distribution
ddd-3.2.tar.gz contains this manual as
pre-formatted PDF file; you can also download it from
the DDD WWW page.
A pre-formatted HTML version of this manual comes
in a separate DDD package
ddd-3.2-html-manual.tar.gz; you can browse
and download it via
the DDD WWW page.
The manual itself is written in TeXinfo format; its source code
ddd.texi is contained in the DDD source distribution
ddd-3.2.tar.gz.
The picture sources come in a separate package
ddd-3.2-pics.tar.gz; you need this package
only if you want to re-create the PostScript, HTML, or PDF versions.
DDD is free; this means that everyone is free to use it and free to redistribute it on a free basis. DDD is not in the public domain; it is copyrighted and there are restrictions on its distribution, but these restrictions are designed to permit everything that a good cooperating citizen would want to do. What is not allowed is to try to prevent others from further sharing any version of DDD that they might get from you. The precise conditions are found in the GNU General Public License that comes with DDD; See License, for details.
The easiest way to get a copy of DDD is from someone else who has it. You need not ask for permission to do so, or tell any one else; just copy it.
If you have access to the Internet, you can get the latest version of
DDD from the anonymous FTP server ftp.gnu.org in the
directory /gnu/ddd. This should contain the following files:
ddd-version.tar.gzddd-version-html-manual.tar.gzddd-version-pics.tar.gzDDD can also be found at numerous other archive sites around the
world; check the file ANNOUNCE in a DDD distribution for
the latest known list.
Dorothea Lütkehaus and Andreas Zeller were the original authors of
DDD. Many others have contributed to its development. The
files ChangeLog and THANKS in the DDD distribution
approximates a blow-by-blow account.
The history of DDD is a story of code recycling. The oldest parts of DDD were written in 1990, when Andreas Zeller designed VSL, a box-based visual structure language for visualizing data and program structures. The VSL interpreter and the Box library became part of Andreas' Diploma Thesis, a graphical syntax editor based on the Programming System Generator PSG.
In 1992, the VSL and Box libraries were recycled for the NORA project. For NORA, an experimental inference-based software development tool set, Andreas wrote a graph editor (based on VSL and the Box libraries) and facilities for inter-process knowledge exchange. Based on these tools, Dorothea Lütkehaus (now Dorothea Krabiell) realized DDD as her Diploma Thesis, 1994
The original DDD had no source window; this was added by Dorothea during the winter of 1994-1995. In the first quarter of 1995, finally, Andreas completed DDD by adding command and execution windows, extensions for DBX and remote debugging as well as configuration support for several architectures. Since then, Andreas has further maintained and extended DDD, based on the comments and suggestions of several DDD users around the world. See the comments in the DDD source for details.
Major DDD events:
You can use this manual at your leisure to read all about DDD. However, a handful of features are enough to get started using the debugger. This chapter illustrates those features.
The sample program sample.c (see Sample Program) exhibits the
following bug. Normally, sample should sort and print its
arguments numerically, as in the following example:
$ ./sample 8 7 5 4 1 3 1 3 4 5 7 8
However, with certain arguments, this goes wrong:
$ ./sample 8000 7000 5000 1000 4000 1000 1913 4000 5000 7000
Although the output is sorted and contains the right number of
arguments, some arguments are missing and replaced by bogus numbers;
here, 8000 is missing and replaced by
1913.3
Let us use DDD to see what is going on. First, you must compile
sample.c for debugging (see Compiling for Debugging), giving
the -g flag while compiling:
$ gcc -g -o sample sample.c
sample.c
Now, you can invoke DDD (see Invocation) on the
sample executable:
$ ddd sample
After a few seconds, DDD comes up. The Source Window
contains the source of your debugged program; use the Scroll Bar
to scroll through the file.
The Debugger Console (at the bottom) contains DDD version information as well as a GDB prompt.4
GNU DDD Version 3.2, by Dorothea Lütkehaus and Andreas Zeller. Copyright © 1999 Technische Universität Braunschweig, Germany. Copyright © 1999 Universität Passau, Germany. Reading symbols from sample...done. (gdb)
The first thing to do now is to place a Breakpoint
(see Breakpoints), making sample stop at a location you are
interested in. Click on the blank space left to the initialization of
a. The Argument field (): now contains the location
(sample.c:31). Now, click on Break to create a breakpoint
at the location in (). You see a little red stop sign appear in
line 31.
The next thing to do is to actually execute the program, such that
you can examine its behavior (see Running). Select Program
=> Run to execute the program; the Run Program dialog
appears.
In Run with Arguments, you can now enter arguments for the
sample program. Enter the arguments resulting in erroneous
behavior here--that is, 8000 7000 5000 1000 4000. Click on
Run to start execution with the arguments you just entered.
GDB now starts sample. Execution stops after a few moments as
the breakpoint is reached. This is reported in the debugger console.
(gdb) break sample.c:31 Breakpoint 1 at 0x8048666: file sample.c, line 31. (gdb) run 8000 7000 5000 1000 4000 Starting program: sample 8000 7000 5000 1000 4000 Breakpoint 1, main (argc=6, argv=0xbffff918) at sample.c:31 (gdb)
The current execution line is indicated by a green arrow.
=> a = (int *)malloc((argc - 1) * sizeof(int));
You can now examine the variable values. To examine a simple variable,
you can simply move the mouse pointer on its name and leave it there.
After a second, a small window with the variable value pops up
(see Value Tips). Try this with argv to see its value
(6). The local variable a is not yet initialized; you'll
probably see 0x0 or some other invalid pointer value.
To execute the current line, click on the Next button on the
command tool. The arrow advances to the following line. Now, point
again on a to see that the value has changed and that a
has actually been initialized.
To examine the individual values of the a array, enter
a[0] in the argument field (you can clear it beforehand by
clicking on ():) and then click on the Print button. This
prints the current value of () in the debugger console
(see Printing Values). In our case, you'll get
(gdb) print a[0] $1 = 0 (gdb)
or some other value (note that a has only been allocated, but the
contents have not yet been initialized).
To see all members of a at once, you must use a special GDB
operator. Since a has been allocated dynamically, GDB does not
know its size; you must specify it explicitly using the @
operator (see Array Slices). Enter a[0]@(argc - 1) in the
argument field and click on the Print button. You get the first
argc - 1 elements of a, or
(gdb) print a[0]@(argc - 1)
$2 = {0, 0, 0, 0, 0}
(gdb)
Rather than using Print at each stop to see the current value of
a, you can also display a, such that its is
automatically displayed. With a[0]@(argc - 1) still being shown
in the argument field, click on Display. The contents of
a are now shown in a new window, the Data Window. Click on
Rotate to rotate the array horizontally.
Now comes the assignment of a's members:
=> for (i = 0; i < argc - 1; i++)
a[i] = atoi(argv[i + 1]);
You can now click on Next and Next again to see how the
individual members of a are being assigned. Changed members are
highlighted.
To resume execution of the loop, use the Until button. This
makes GDB execute the program until a line greater than the current is
reached. Click on Until until you end at the call of
shell_sort in
=> shell_sort(a, argc);
At this point, a's contents should be 8000 7000 5000 1000
4000. Click again on Next to step over the call to
shell_sort. DDD ends in
=> for (i = 0; i < argc - 1; i++)
printf("%d ", a[i]);
and you see that after shell_sort has finished, the contents of
a are 1000, 1913, 4000, 5000, 7000--that is,
shell_sort has somehow garbled the contents of a.
To find out what has happened, execute the program once again. This
time, you do not skip through the initialization, but jump directly into
the shell_sort call. Delete the old breakpoint by selecting it
and clicking on Clear. Then, create a new breakpoint in line 35
before the call to shell_sort. To execute the program once
again, select Program => Run Again.
Once more, DDD ends up before the call to shell_sort:
=> shell_sort(a, argc);
This time, you want to examine closer what shell_sort is doing.
Click on Step to step into the call to shell_sort. This
leaves your program in the first executable line, or
=> int h = 1;
while the debugger console tells us the function just entered:
(gdb) step shell_sort (a=0x8049878, size=6) at sample.c:9 (gdb)
This output that shows the function where sample is now suspended
(and its arguments) is called a stack frame display. It shows a
summary of the stack. You can use Status => Backtrace to
see where you are in the stack as a whole; selecting a line (or clicking
on Up and Down) will let you move through the stack. Note
how the a display disappears when its frame is left.
Let us now check whether shell_sort's arguments are correct.
After returning to the lowest frame, enter a[0]@size in the
argument field and click on Print:
(gdb) print a[0] @ size
$4 = {8000, 7000, 5000, 1000, 4000, 1913}
(gdb)
Surprise! Where does this additional value 1913 come from? The
answer is simple: The array size as passed in size to
shell_sort is too large by one--1913 is a bogus
value which happens to reside in memory after a. And this last
value is being sorted in as well.
To see whether this is actually the problem cause, you can now assign
the correct value to size (see Assignment). Select
size in the source code and click on Set. A dialog pops
up where you can edit the variable value.
Change the value of size to 5 and click on OK.
Then, click on Finish to resume execution of the
shell_sort function:
(gdb) set variable size = 5 (gdb) finish Run till exit from #0 shell_sort (a=0x8049878, size=5) at sample.c:9 0x80486ed in main (argc=6, argv=0xbffff918) at sample.c:35 (gdb)
Success! The a display now contains the correct values
1000, 4000, 5000, 7000, 8000.
You can verify that these values are actually printed to standard output
by further executing the program. Click on Cont to continue
execution.
(gdb) cont 1000 4000 5000 7000 8000 Program exited normally. (gdb)
The message Program exited normally. is from GDB; it indicates
that the sample program has finished executing.
Having found the problem cause, you can now fix the source code. Click
on Edit to edit sample.c, and change the line
shell_sort(a, argc);
to the correct invocation
shell_sort(a, argc - 1);
You can now recompile sample
$ gcc -g -o sample sample.c
and verify (via Program => Run Again) that sample
works fine now.
(gdb) run `sample' has changed; re-reading symbols. Reading in symbols...done. Starting program: sample 8000 7000 5000 1000 4000 1000 4000 5000 7000 8000 Program exited normally. (gdb)
All is done; the program works fine now. You can end this DDD
session with Program => Exit or Ctrl+Q.
Here's the source sample.c of the sample program.
/* sample.c -- Sample C program to be debugged with DDD */
#include <stdio.h>
#include <stdlib.h>
static void shell_sort(int a[], int size)
{
int i, j;
int h = 1;
do {
h = h * 3 + 1;
} while (h <= size);
do {
h /= 3;
for (i = h; i < size; i++)
{
int v = a[i];
for (j = i; j >= h && a[j - h] > v; j -= h)
a[j] = a[j - h];
if (i != j)
a[j] = v;
}
} while (h != 1);
}
int main(int argc, char *argv[])
{
int *a;
int i;
a = (int *)malloc((argc - 1) * sizeof(int));
for (i = 0; i < argc - 1; i++)
a[i] = atoi(argv[i + 1]);
shell_sort(a, argc);
for (i = 0; i < argc - 1; i++)
printf("%d ", a[i]);
printf("\n");
free(a);
return 0;
}
This chapter discusses how to start DDD, and how to get out of it. The essentials are:
Normally, you can run DDD by invoking the program
ddd.
You can also run DDD with a variety of arguments and options, to specify more of your debugging environment at the outset.
The most usual way to start DDD is with one argument, specifying an executable program:
ddd program
If you use GDB, DBX, Ladebug, or XDB as inferior debuggers, you can also start with both an executable program and a core file specified:
ddd program core
You can, instead, specify a process ID as a second argument, if you want to debug a running process:
ddd program 1234
would attach DDD to process 1234 (unless you also have a file
named 1234; DDD does check for a core file first).
You can further control DDD by invoking it with specific options. To get a list of DDD options, invoke DDD as
ddd --help
Most important are the options to specify the inferior debugger (see Choosing an Inferior Debugger), but you can also customize several aspects of DDD upon invocation (see Options).
DDD also understands the usual X options such as -display
or -geometry. See X Options, for details.
All arguments and options that are not understood by DDD are
passed to the inferior debugger; See Inferior Debugger Options, for a
survey. To pass an option to the inferior debugger that conflicts with
an X option, or with a DDD option listed here, use the
--debugger option (see Options).
The most frequently required options are those to choose a specific inferior debugger.
Normally, the inferior debugger is determined by the program to analyze:
Use
ddd --jdb program
ddd --pydb program
ddd --perl program
to run DDD with JDB, PYDB, or Perl as inferior debugger.
Use
ddd --gdb program
ddd --dbx program
ddd --ladebug program
ddd --xdb program
to run DDD with GDB, DBX, Ladebug, or XDB as inferior debugger.
If you invoke DDD without any of these options, but give a program to analyze, then DDD will automatically determine the inferior debugger:
See Customizing Debugger Interaction, for more details on determining the inferior debugger.
You can further control how DDD starts up using the following
options. All options may be abbreviated, as long as they are
unambiguous; single dashes - instead of double dashes --
may also be used. Almost all options control a specific DDD
resource or resource class (see Customizing).
--attach-windows
Giving this option is equivalent to setting the DDD
Separate resource class to off. See Window Layout, for
details.
--attach-source-window
Giving this option is equivalent to setting the DDD
separateSourceWindow resource to off.
See Window Layout, for details.
--attach-data-window
Giving this option is equivalent to setting the DDD
separateDataWindow resource to off. See Window Layout,
for details.
--automatic-debugger
Giving this option is equivalent to setting the DDD
autoDebugger resource to on.
See Customizing Debugger Interaction, for details.
--button-tips
Giving this option is equivalent to setting the DDD
buttonTips resource to on. See Customizing Help, for
details.
--configuration
Giving this option is equivalent to setting the DDD
showConfiguration resource to on. See Diagnostics, for
details.
--check-configuration
Giving this option is equivalent to setting the DDD
checkConfiguration resource to on. See Diagnostics,
for details.
--data-window
Giving this option is equivalent to setting the DDD
openDataWindow resource to on. See Toggling Windows,
for details.
--dbx
Giving this option is equivalent to setting the DDD
debugger resource to dbx.
See Customizing Debugger Interaction, for details.
--debugger name
gdb, dbx, xdb,
jdb, pydb, or perl).
This option can also be used to pass options to the inferior debugger
that would otherwise conflict with DDD options. For instance,
to pass the option -d directory to XDB, use:
ddd --debugger "xdb -d directory"
If you use the --debugger option, be sure that the type of
inferior debugger is specified as well. That is, use one of the options
--gdb, --dbx, --xdb, --jdb, --pydb,
or --perl (unless the default setting works fine).
Giving this option is equivalent to setting the DDD
debuggerCommand resource to name. See Customizing Debugger Interaction, for details.
--debugger-console
Giving this option is equivalent to setting the DDD
openDebuggerConsole resource to on. See Toggling Windows, for details.
--disassemble
--no-disassemble
option, below.
Giving this option is equivalent to setting the DDD
disassemble resource to on. See Customizing Source,
for details.
--exec-window
Giving this option is equivalent to setting the DDD
separateExecWindow resource to on. See Customizing the Execution Window, for details.
--font fontname
-fn fontname
Giving this option is equivalent to setting the DDD
defaultFont resource to fontname. See Customizing Fonts, for details.
--fonts
Giving this option is equivalent to setting the DDD
showFonts resource to on. See Diagnostics, for
details.
--fontsize size
--fontsize 120.
Giving this option is equivalent to setting the DDD
FontSize resource class to size. See Customizing Fonts, for details.
--fullname
-f
-fullname format
suitable for debugger front-ends. By default, both the debugger console
and source window are disabled. See TTY mode, for a discussion.
Giving this option is equivalent to setting the DDD
TTYMode resource class to on. See TTY mode, for
details.
--gdb
Giving this option is equivalent to setting the DDD
debugger resource to gdb. See Customizing Debugger Interaction,
for details.
--glyphs
--no-glyphs option, below.
Giving this option is equivalent to setting the DDD
displayGlyphs resource to on. See Customizing Source,
for details.
--help
-h
-?
Giving this option is equivalent to setting the DDD
showInvocation resource to on. See Diagnostics, for
details.
--host hostname
--host username@hostname
--login option is not used,
use username as remote user name. See Remote Debugger, for
details.
Giving this option is equivalent to setting the DDD
debuggerHost resource to hostname. See Remote Debugger,
for details.
--jdb
Giving this option is equivalent to setting the DDD
debugger resource to gdb. See Customizing Debugger Interaction,
for details.
--ladebug
Giving this option is equivalent to setting the DDD
debugger resource to ladebug. See Customizing Debugger Interaction, for details.
--lesstif-hacks
--lesstif-version 999. Deprecated.
Giving this option is equivalent to setting the DDD
lessTifVersion resource to 999. See LessTif, for
details.
--lesstif-version version
Giving this option is equivalent to setting the DDD
lessTifVersion resource to version. See LessTif, for
details.
--license
Giving this option is equivalent to setting the DDD
showLicense resource to on. See Diagnostics, for
details.
--login username
-l username
Giving this option is equivalent to setting the DDD
debuggerHostLogin resource to username. See Remote Debugger, for details.
--maintenance
Maintenance menu with options for debugging
DDD. See Maintenance Menu, for details.
Giving this option is equivalent to setting the DDD
maintenance resource to on. See Maintenance Menu, for
details.
--manual
Giving this option is equivalent to setting the DDD
showManual resource to on. See Diagnostics, for
details.
--news
Giving this option is equivalent to setting the DDD
showNews resource to on. See Diagnostics, for details.
--no-button-tips
Giving this option is equivalent to setting the DDD
buttonTips resource to off. See Customizing Help, for
details.
--no-data-window
Giving this option is equivalent to setting the DDD
openDataWindow resource to off. See Toggling Windows,
for details.
--no-debugger-console
Giving this option is equivalent to setting the DDD
openDebuggerConsole resource to off. See Toggling Windows, for details.
--no-disassemble
Giving this option is equivalent to setting the DDD
disassemble resource to off. See Customizing Source,
for details.
--no-exec-window
Giving this option is equivalent to setting the DDD
separateExecWindow resource to off. See Customizing the Execution Window, for details.
--no-glyphs
Giving this option is equivalent to setting the DDD
displayGlyphs resource to off. See Customizing Source,
for details.
--no-lesstif-hacks
--lesstif-version 1000. Deprecated.
Giving this option is equivalent to setting the DDD
lessTifVersion resource to 1000. See LessTif, for
details.
--no-maintenance
Maintenance menu with options for
debugging DDD. This is the default. See Maintenance Menu,
for details.
Giving this option is equivalent to setting the DDD
maintenance resource to off. See Maintenance Menu, for
details.
--no-source-window
Giving this option is equivalent to setting the DDD
openSourceWindow resource to off. See Toggling Windows, for details.
--no-value-tips
Giving this option is equivalent to setting the DDD
valueTips resource to off. See Value Tips, for
details.
--nw
--perl
Giving this option is equivalent to setting the DDD
debugger resource to perl. See Customizing Debugger Interaction,
for details.
--pydb
Giving this option is equivalent to setting the DDD
debugger resource to pydb. See Customizing Debugger Interaction,
for details.
--panned-graph-editor
--scrolled-graph-editor, below.
Giving this option is equivalent to setting the DDD
pannedGraphEditor resource to on. See Customizing Displays, for details.
--play-log log-file
ddd --play-log log-file
invokes DDD as inferior debugger, simulating the inferior debugger given in log-file (see below). This is useful for debugging DDD.
Giving this option is equivalent to setting the DDD
playLog resource to on. See Customizing Debugger Interaction, for
details.
--PLAY log-file
$HOME/.ddd/log file as generated by some previous
DDD session (see Logging). When a command is entered, scan
log-file for this command and re-issue the logged reply; if the
command is not found, do nothing. This is used by the --play
option.
--rhost hostname
--rhost username@hostname
--login
option is not used, use username as remote user name.
See Remote Debugger, for details.
Giving this option is equivalent to setting the DDD
debuggerRHost resource to hostname. See Remote Debugger, for details.
--scrolled-graph-editor
--panned-graph-editor, above.
Giving this option is equivalent to setting the DDD
pannedGraphEditor resource to off. See Customizing Displays, for details.
--separate-windows
--separate
--attach options, above.
Giving this option is equivalent to setting the DDD
Separate resource class to off. See Window Layout, for
details.
--session session
Giving this option is equivalent to setting the DDD
session resource to session. See Resuming Sessions, for
details.
--source-window
Giving this option is equivalent to setting the DDD
openSourceWindow resource to on. See Toggling Windows,
for details.
--status-at-bottom
Giving this option is equivalent to setting the DDD
statusAtBottom resource to on. See Window Layout, for
details.
--status-at-top
Giving this option is equivalent to setting the DDD
statusAtBottom resource to off. See Window Layout, for
details.
--sync-debugger
Giving this option is equivalent to setting the DDD
synchronousDebugger resource to on. See Customizing Debugger Interaction, for details.
--toolbars-at-bottom
Giving this option is equivalent to setting the DDD
toolbarsAtBottom resource to on. See Window Layout,
for details.
--toolbars-at-top
Giving this option is equivalent to setting the DDD
toolbarsAtBottom resource to off. See Window Layout,
for details.
--trace
--trace is not specified, this information is written into
~/.ddd/log (~ stands for your home directory),
such that you can also do a post-mortem debugging. See Logging, for
details about logging.
Giving this option is equivalent to setting the DDD trace
resource to on. See Diagnostics, for details.
--tty
-t
Giving this option is equivalent to setting the DDD
ttyMode resource to on. See TTY mode, for details.
--value-tips
Giving this option is equivalent to setting the DDD
valueTips resource to on. See Value Tips, for details.
--version
-v
Giving this option is equivalent to setting the DDD
showVersion resource to on. See Diagnostics, for
details.
--vsl-library library
Giving this option is equivalent to setting the DDD
vslLibrary resource to library. See Customizing Display Appearance, for details.
--vsl-path path
Giving this option is equivalent to setting the DDD
vslPath resource to path. See Customizing Display Appearance, for details.
--vsl-help
--xdb
Giving this option is equivalent to setting the DDD
debugger resource to xdb. See Customizing Debugger Interaction, for details.
DDD also understands the following X options. Note that these
options only take a single dash -.
-display display
DISPLAY environment variable.
-geometry geometry
-iconic
-name name
-selectionTimeout timeout
-title name
-xrm resourcestring
All options that DDD does not recognize are passed to the inferior debugger. This section lists the most useful options of the different inferior debuggers supported by DDD.
These GDB options are useful when using DDD with GDB as inferior
debugger. Single dashes - instead of double dashes -- may
also be used.
-b baudrate
--cd dir
--command file
--core corefile
--directory dir
-d dir
--exec execfile
--mapped
--nx
-n
.gdbinit file.
--readnow
--se file
--symbols symfile
See Invoking GDB, for further options that can be used with GDB.
DBX variants differ widely in their options, so we cannot give a list here. Check out the dbx(1) and ladebug(1) manual pages.
These XDB options are useful when using DDD with XDB as inferior debugger.
-d dir
-P process-id
-l library
-l
ALL means always pre-load shared library information.
-S num
-s
Further options can be found in the xdb(1) manual page.
The following JDB options are useful when using DDD with JDB as inferior debugger.
-host hostname
-password psswd
-debug)
These JDB options are forwarded to debuggee process:
-verbose
-v
-debug
-noasyncgc
-verbosegc
-noclassgc
-checksource
-cs
-ss number
-oss number
-ms number
-mx number
-Dname=value
-classpath path
-prof
-prof:file
./java.prof. If file is given,
write the data to ./file.
-verify
-verifyremote
-noverify
-dbgtrace
Further options can be found in the JDB documentation.
For a list of useful PYDB options, check out the PYDB documentation.
The most important Perl option to use with DDD is -w; it
enables several important warnings. For further options, see the
perlrun(1) manual page.
If you have multiple DDD instances running, they share common preferences and history files. This means that changes applied to one instance may get lost when being overwritten by the other instance. DDD has two means to protect you against unwanted losses. The first means is an automatic reloading of changed options, controlled by the following resource (see Customizing):
| checkOptions (class CheckOptions) | Resource |
Every n seconds, where n is the value of this resource,
DDD checks whether the options file has changed. Default is
30, which means that every 30 seconds, DDD checks for the
options file. Setting this resource to 0 disables checking for
changed option files.
|
Normally, automatic reloading of options should already suffice. If you
need stronger protection, DDD also provides a warning against
multiple instances. This warning is disabled by default, If you want to
be warned about multiple DDD invocations sharing the same
preferences and history files, enable Edit => Preferences
=> Warn if Multiple DDD Instances are Running.
This setting is tied to the following resource (see Customizing):
| warnIfLocked (class WarnIfLocked) | Resource |
Whether to warn if multiple DDD instances are running
(on) or not (off, default).
|
If you are bothered by X warnings, you can suppress them by setting
Edit => Preferences => General => Suppress X
warnings.
This setting is tied to the following resource (see Customizing):
| suppressWarnings (class SuppressWarnings) | Resource |
If on, X warnings are suppressed. This is
sometimes useful for executables that were built on a machine with a
different X or Motif configuration. By default, this is
off.
|
To exit DDD, select File => Exit. You may also
type the quit command at the debugger prompt or press
<Ctrl+Q>. GDB and XDB also accept the q command or an
end-of-file character (usually <Ctrl+D>). Closing the last
DDD window will also exit DDD.
An interrupt (<ESC> or Interrupt) does not exit from
DDD, but rather terminates the action of any debugger command
that is in progress and returns to the debugger command level. It is
safe to type the interrupt character at any time because the debugger
does not allow it to take effect until a time when it is safe.
In case an ordinary interrupt does not succeed, you can also use an
abort (<Ctrl+\> or Abort), which sends a SIGABRT
signal to the inferior debugger. Use this in emergencies only; the
inferior debugger may be left inconsistent or even exit after a
SIGABRT signal.
As a last resort (if DDD hangs, for example), you may also
interrupt DDD itself using an interrupt signal (SIGINT).
This can be done by typing the interrupt character (usually
<Ctrl+C>) in the shell DDD was started from, or by using the
UNIX kill command. An interrupt signal interrupts any
DDD action; the inferior debugger is interrupted as well. Since
this interrupt signal can result in internal inconsistencies, use this
as a last resort in emergencies only; save your work as soon as possible
and restart DDD.
If you want to interrupt your current DDD session, you can save the entire the entire DDD state as session on disk and resume later.
To save a session, select File => Save Session As. You will
be asked for a symbolic session name session.
If your program is running (see Running), or if you have opened a core file (see Opening Core Dumps), DDD can also include a core file in the session such that the debuggee data will be restored when re-opening it. To get a core file, DDD typically must kill the debuggee. This means that you cannot resume program execution after saving a session. Depending on your architecture, other options for getting a core file may also be available.
Including a core dump is necessary for restoring memory contents and the
current execution position. To include a core dump, enable
Include Core Dump.
After clicking on Save, the session is saved in
~/.ddd/sessions/session.
Here's a list of the items whose state is saved in a session:
After saving the current state as a session, the session becomes active. This means that DDD state will be saved as session defaults:
~/.ddd/sessions/session/init instead of
~/.ddd/init. See Saving Options, for details.
~/.ddd/sessions/session/history instead of
~/.ddd/history. See Command History, for details.
To make the current session inactive, open the default session
named [None]. See Resuming Sessions, for details on opening
sessions.
To resume a previously saved session, select File => Open
Session and choose a session name from the list. After clicking on
Open, the entire DDD state will be restored from the
given session.
The session named [None] is the default session which is
active when starting DDD. To save options for default sessions,
open the default session and save options. See Saving Options, for
details.
If a the restored session includes a core dump, the program being debugged will be in the same state at the time the session was saved; in particular, you can examine the program data. However, you will not be able to resume program execution since the process and its environment (open files, resources, etc.) no longer exist. However, you can restart the program, re-using the restored breakpoints and data displays.
Opening sessions also restores command definitions, buttons, display shortcuts and the source tab width. This way, you can maintain a different set of definitions for each session.
You can also specify a session to open when starting DDD. To invoke DDD with a session session, use
ddd --session session
There is also a shortcut that opens the session session and invokes the inferior debugger on an executable named session (in case session cannot be opened):
ddd =session
There is no need to give further command-line options when restarting a session, as they will be overridden by the options saved in the session.
You can also use an X session manager such as xsm to save and
restore DDD sessions.7 When
being shut down by a session manager, DDD saves its state under
the name specified by the session manager; resuming the X session makes
DDD reload its saved state.
To delete sessions that are no longer needed, select File
=> Open Session or File => Save Session. Select
the sessions you want to delete and click on Delete.
The default session [None] cannot be deleted.
You can change the place where DDD saves its sessions by setting
the environment variable DDD_SESSIONS to the name of a directory.
Default is ~/.ddd/sessions/.
Where applicable, DDD supports a gcore command to obtain
core files of the running program. You can enter its path via
Edit => Preferences => Helpers => Get Core
File. Leave the value empty if you have no gcore or similar
command.
This setting is tied to the following resource (see Customizing):
| getCoreCommand (class GetCoreCommand) | Resource |
A command to get a core dump of a running process (typically,
gcore) @FILE@ is replaced by the base name of the file
to create; @PID@ is replaced by the process id. The output
must be written to @FILE@.@PID@.
Leave the value empty if you have no |
You can have each of DDD, the inferior debugger, and the debugged program run on different machines.
You can run DDD on a remote host, using your current host as X display. On the remote host, invoke DDD as
ddd -display display
where display is the name of the X server to connect to (for
instance, hostname:0.0, where hostname is your host).
Instead of specifying -display display, you can also set
the DISPLAY environment variable to display.
In order to run the inferior debugger on a remote host, you need
remsh (called rsh on BSD systems) access on the remote
host.
To run the debugger on a remote host hostname, invoke DDD as
ddd --host hostname remote-program
If your remote username differs from the local username, use
ddd --host hostname --login username remote-program
or
ddd --host username@hostname remote-program
instead.
There are a few caveats in remote mode:
--rhost option instead of --host. This
will invoke the remote debugger via an interactive shell on the remote
host, which may lead to better results.
Note: using --rhost, DDD invokes the inferior debugger as
soon as a shell prompt appears. The first output on the remote host
ending in a space character or > and not followed by a newline is
assumed to be a shell prompt. If necessary, adjust your shell prompt on
the remote host.
xterm terminal
emulator on the remote host, giving your current DISPLAY
environment variable as address. If the remote host cannot invoke
xterm, or does not have access to your X display, start
DDD with the --no-exec-window option. The program
input/output will then go through the DDD debugger console.
--trace option. This prints the shell commands issued by
DDD on standard error.
See Customizing Remote Debugging, for customizing remote mode.
When having the inferior debugger run on a remote host (see Remote Debugging), all commands to access the inferior debugger as well as its files must be run remotely. This is controlled by the following resources (see Customizing):
| rshCommand (class RshCommand) | Resource |
The remote shell command to invoke TTY-based commands on
remote hosts. Usually, remsh, rsh, ssh,
or on.
|
| listCoreCommand (class listCoreCommand) | Resource |
The command to list all core files on the remote host. The string
@MASK@ is replaced by a file filter. The default setting is:
Ddd*listCoreCommand: \ file @MASK@ | grep '.*:.*core.*' | cut -d: -f1 |
| listDirCommand (class listDirCommand) | Resource |
The command to list all directories on the remote host. The string
@MASK@ is replaced by a file filter. The default setting is:
Ddd*listDirCommand: \ file @MASK@ | grep '.*:.*directory.*' | cut -d: -f1 |
| listExecCommand (class listExecCommand) | Resource |
The command to list all executable files on the remote host. The string
@MASK@ is replaced by a file filter. The default setting is:
Ddd*listExecCommand: \ file @MASK@ | grep '.*:.*exec.*' \ | grep -v '.*:.*script.*' \ | cut -d: -f1 | grep -v '.*\.o$' |
| listSourceCommand (class listSourceCommand) | Resource |
The command to list all source files on the remote host. The string
@MASK@ is replaced by a file filter. The default setting is:
Ddd*listSourceCommand: \ file @MASK@ | grep '.*:.*text.*' | cut -d: -f1 |
The GDB debugger allows you to run the debugged program on a remote machine (called remote target), while GDB runs on the local machine.
See Remote, for details. Basically, the following steps are required:
gdbserver on the remote target.
file command.
gdbserver using the GDB target remote
command.
The local .gdbinit file is useful for setting up directory search
paths, etc.
Of course, you can also combine DDD remote mode and GDB remote mode, running DDD, GDB, and the debugged program each on a different machine.
These settings control the interaction of DDD with its inferior debugger.
To choose the default inferior debugger, select Edit =>
Preferences => Startup => Debugger Type. You can
Determine
Automatically from Arguments to enable.
Debugger Type.
The following DDD resources control the invocation of the inferior debugger (see Customizing).
| autoDebugger (class AutoDebugger) | Resource |
If this is on (default), DDD will attempt to determine
the debugger type from its arguments, possibly overriding the
debugger resource (see below). If this is off,
DDD will invoke the debugger specified by the debugger
resource regardless of DDD arguments.
|
| debugger (class Debugger) | Resource |
The type of the inferior debugger to invoke (gdb, dbx,
ladebug, xdb, jdb, pydb, or perl).
This resource is usually set through the |
| debuggerCommand (class DebuggerCommand) | Resource |
The name under which the inferior debugger is to be invoked. If this
string is empty (default), the debugger type (debugger resource)
is used.
This resource is usually set through the |
DDD uses a number of resources to initialize the inferior debugger (see Customizing).
| gdbInitCommands (class InitCommands) | Resource |
This string contains a list of newline-separated commands that are
initially sent to GDB. As a side-effect, all settings
specified in this resource are considered fixed and cannot be changed
through the GDB settings panel, unless preceded by white
space. By default, the gdbInitCommands resource contains some
settings vital to DDD:
Ddd*gdbInitCommands: \ set height 0\n\ set width 0\n\ set verbose off\n\ set prompt (gdb) \n While the Do not use this resource to customize GDB; instead, use a
personal |
| gdbSettings (class Settings) | Resource |
This string contains a list of newline-separated commands that are
also initially sent to GDB. Its default value is
Ddd*gdbSettings: \ set print asm-demangle on\n This resource is used to save and restore the debugger settings. |
| sourceInitCommands (class SourceInitCommands) | Resource |
If on (default), DDD writes all GDB initialization
commands into a temporary file and makes GDB read this file, rather than
sending each initialization command separately. This results in faster
startup (especially if you have several user-defined commands). If
off, DDD makes GDB process each command separately.
|
| dbxInitCommands (class InitCommands) | Resource |
|
This string contains a list of newline-separated commands that are
initially sent to DBX. By default, it is empty.
Do not use this resource to customize DBX; instead, use a
personal |
| dbxSettings (class Settings) | Resource |
| This string contains a list of newline-separated commands that are also initially sent to DBX. By default, it is empty. |
| xdbInitCommands (class InitCommands) | Resource |
|
This string contains a list of newline-separated commands that are
initially sent to XDB. By default, it is empty.
Do not use this resource to customize DBX; instead, use a
personal |
| xdbSettings (class Settings) | Resource |
| This string contains a list of newline-separated commands that are also initially sent to XDB. By default, it is empty. |
| jdbInitCommands (class InitCommands) | Resource |
| This string contains a list of newline-separated commands that are initially sent to JDB. This resource may be used to customize JDB. By default, it is empty. |
| jdbSettings (class Settings) | Resource |
|
This string contains a list of newline-separated commands that are
also initially sent to JDB. By default, it is empty.
This resource is used by DDD to save and restore JDB settings. |
| pydbInitCommands (class InitCommands) | Resource |
|
This string contains a list of newline-separated commands that are
initially sent to PYDB. By default, it is empty.
This resource may be used to customize PYDB. |
| pydbSettings (class Settings) | Resource |
|
This string contains a list of newline-separated commands that are
also initially sent to PYDB. By default, it is empty.
This resource is used by DDD to save and restore PYDB settings. |
| perlInitCommands (class InitCommands) | Resource |
|
This string contains a list of newline-separated commands that are
initially sent to the Perl debugger. By default, it is empty.
This resource may be used to customize the Perl debugger. |
| perlSettings (class Settings) | Resource |
|
This string contains a list of newline-separated commands that are
also initially sent to the Perl debugger. By default, it is empty.
This resource is used by DDD to save and restore Perl debugger settings. |
| openSelection (class OpenSelection) | Resource |
If this is on, DDD invoked without argument checks
whether the current selection or clipboard contains the file name or
URL of an executable program. If this is so, DDD
will automatically open this program for debugging. If this resource
is off (default), DDD invoked without arguments will
always start without a debugged program.
|
The following resources control the communication with the inferior debugger.
| blockTTYInput (class BlockTTYInput) | Resource |
Whether DDD should block when reading data from the inferior debugger
via the pseudo-tty interface. Most UNIX systems except GNU/Linux
require this; set it to on. On GNU/Linux, set it to
off. The value auto (default) will always select the
"best" choice (that is, the best choice known to the DDD
developers).
|
| displayTimeout (class DisplayTimeout) | Resource |
The time (in ms) to wait for the inferior debugger to finish a partial
display information. Default is 2000.
|
| positionTimeout (class PositionTimeout) | Resource |
The time (in ms) to wait for the inferior debugger to finish a partial
position information. Default is 500.
|
| questionTimeout (class QuestionTimeout) | Resource |
The time (in seconds) to wait for the inferior debugger to reply.
Default is 10.
|
| synchronousDebugger (class SynchronousDebugger) | Resource |
If on, X events are not processed while the debugger is busy.
This may result in slightly better performance on single-processor
systems. See Options, for the --sync-debugger option.
|
| terminateOnEOF (class TerminateOnEOF) | Resource |
If on, DDD terminates the inferior debugger when
DDD detects an EOF condition (that is, as soon as the inferior
debugger closes its output channel). This was the default behavior in
DDD 2.x and earlier. If off (default), DDD takes
no special action.
|
| useTTYCommand (class UseTTYCommand) | Resource |
If on, use the GDB tty command for redirecting
input/output to the separate execution window. If off, use
explicit redirection through shell redirection operators < and
>. The default is off (explicit redirection), since on
some systems, the tty command does not work properly on some
GDB versions.
|
DDD is composed of three main windows. From top to bottom, we have:
Besides these three main windows, there are some other optional windows:
The DDD Menu Bar gives you access to all DDD functions.
File
Edit
View
Program
Commands
Status
Source
Data
Maintenance
Help
There are two ways of selecting an item from a pull-down menu: