dbx is a symbolic debugger for compiled programs

Last revision August 4, 2004

Additional topics Using dbx to see why a program is crashing

The dbx debugger allows you to examine the core (or memory image) file that is created when a program abnormally terminates (crashes), in order to find out which function or statement was executing when it crashed, and what the values of variables were.

dbx also permits you to run the program from the start, showing source code lines as they are executed, or forcing the program to stop at preselected points (particular lines, particular routines, or whenever particular variables are assigned) so you can examine values of variables and see what is happening. You can even attach dbx to an already running process under some circumstances, so you can find out what it is doing. See the dbx on-line manual entry for details.

Some version of dbx is found on most Unix systems. dbx is a basic command-line program. In many cases, a fancy graphical interface, using X Window, will also be provided. The command man -k debugger will usually tell you what debugger programs are available on your system.

On pangea, running Tru64 Unix from Compaq, the dbx debugger is available, but considered obsolete, and no further development is occurring for it. Compaq has a new debugger with both command-line and graphical interfaces named ladebug. This is the preferred debugger for Tru64 Unix and is the one that will be continually developed with new features. For the simple case of finding out where a program crashed, however, the basic dbx debugger works well and is easily described here.

dbx on pangea can be used with programs written in the C, Fortran, and Pascal languages. ladebug on pangea works with C, Fortran, C++, Ada, and Cobol programs.

dbx is symbolic, meaning that you can reference points in your code by the names of the routines, the names you have given to variables, or the line numbers in the source code. You work in the same language that you write the program in; you do not need to know assembler or machine language.

Here are some conditions for using the dbx debugger on your program:

• You must specify the -g flag to the f77, f90, f95, or cc compiler when compiling the source code, so that the symbolic names (variable and routine names) will be saved in the executable file for dbx to use. If you try to run dbx and have not compiled with -g, it will give an error message and quit.
• You should not request any optimizations from the f77, f90, f95, or cc compiler when planning to use the debugger. Optimizations can confuse the debugger. Either leave off the -O option (letter "oh") altogether, or on pangea, specify -O0 (letter "oh" followed by zero) which explicitly turns off all optimizations.
• You should run the executable program from the same directory that contains the source code files so that dbx can display the source lines when requested.
• Do not change the source code after compiling and before running dbx.

The simplest use of dbx is to show you which statements your program was running when it crashed. The kernel attempts to save a disk copy of the memory image of a program that crashed, in a file named core in the working directory of the program. This file is needed by dbx to provide information about the reason for the crash. It will only be created if two conditions are met:

• Your program must have write access to its working directory.
• Your coredumpsize resource limit must be set to a value larger than the memory size of your program.

The coredumpsize resource limit is a built-in function of the C-shell that limits the size of a core file you can create on disk. For beginning users, we normally set it to zero in the system .login file, to prevent them from accidentally making core dump files that they wouldn't even know existed, and thus clutter up the file system. If you are doing program development, you can add a line to the end of your .login file to increase the allowable size of core dumps, for example:
       limit coredumpsize 8M
to permit core dumps up to 8 megabytes in size. Or you can just issue the same command directly at the shell prompt before running a program that you think may crash. Be sure to remove core dump files after examining them.