gdb_test

gdb_test a FORTRAN90 code which uses GDB, the GNU debugger program, intended to help programmers find the location and nature of run time errors.

GDB works with programs written in C, C++, FORTRAN77, FORTRAN90, Java, and assembly language.

The most common case in which you'll use GDB occurs when a program you've written crashes, leaving a core file. You may really have no idea where the error occurred, in which case you could waste much time inserting output statements, or tinkering with various routines that turn out not to contain the error. But GDB can help you find the error much more quickly.

In order for GDB to do its best work, it needs a symbol table, which helps it translate the computer addresses of variables to the names you used when setting them up. This symbol table is created at compile time, usually with the -g compile option, as in one of the following:

        gcc -g myprog.c
        g++ -g myprog.C
        f77 -g myprog.f
        f90 -g myprog.f90

If your program has several parts, you will really need to compile each part with the symbol table option, as in

        gcc -g part1.c part2.c part3.c

        gcc -c -g part2.c
        gcc -c -g part3.c
        gcc -g part1.c part2.o part3.o

Of course, your program that crashed probably was not compiled with the symbol table option, so the first step is to recompile the program, rerun it, and presumably, recrash it! If you really had a nice crash, you will now have a core file in your directory, which GDB will also need to examine as it helps you.

If your executable is called a.out, then if you simply type

        gdb a.out core

then GDB will usually be able to report the line of your program on which the fatal error occurred. This assumes, of course, that the core file and original source code files are in the current directory and correspond to the executable program.

In other cases, you may want to run your program from the beginning, with the option to pause execution at certain places, so that you can query the values of certain variables. This entails an interactive session, which might begin like this:

        gdb a.out
        run
        
          Program received signal SIGSEGV, Segmentation fault.
          0x12000162c in test02 () at bounder.f90:119
          119    b(j) = j + 1
          Current language:  auto; currently fortran
        
        
        print i
        $ 1   1000000
        quit

Suppose that your program generally expects command line arguments, so that a typical execution might be

         myprog arg1 arg2 arg3

Then the only thing you have to do is include those same arguments on the run command line:

        gdb myprog
        run arg1 arg2 arg3

Usage:

gdb executable: Loads your executable into gdb. Type "run" to make your program execute.
gdb executable core: Loads your program into gbd along with the core file created when your program crashed.

Licensing:

The computer code and data files described and made available on this web page are distributed under the MIT license

Languages:

gdb_test is available in a FORTRAN90 version.

Reference:

Richard Stallman, Roland Pesch, Stan Shebs,
Debugging with GDB: the GNU Source-Level Debugger,
GNU Press, 2002.
The GDB Home Page,
https://www.gnu.org/software/gdb/

Source code:

gdb_test.sh, runs all the tests.

BOUNDER is an example in which an array index exceeds the array bounds, generating a runtime error. Files you may copy include:

bounder.f90, the source code;
bounder.txt, the output file.

BOUNDER_GDB shows the steps involved in using GDB to track down the problem in BOUNDER. Note that GDB needs access to the executable program that failed. Normally, the GDB is run interactively, and the commands in the input file are entered one at a time by the user.

bounder_gdb_input.txt, input commands to GDB, normally typed interactively. We are most curious to see the value of J.
bounder_gdb.txt, the output from GDB, which normally goes to your screen.

Last revised on 23 January 2020.