Sample Debugging Session

In this section we report a sample debugging session to help a fast debugger startup for beginners. Here we use dbx as it is faster and gives more detailed messages in case of command errors that can be misleading to the debugger. The commands are the same as for ladebug the only difference is that dbx is line oriented and does not support the command recall feature.

Let us suppose that the program to debug is the default a.out image, we start dbx as follows:

> dbx a.out
dbx version 3.11.10
Type 'help' for help.

tst:   3  write(6,*) "tst.f running"
(dbx)

dbx types the first executable statement of the program. The startup prints of ladebug are slightly different:

> ladebug a.out
Welcome to the Ladebug Debugger Version 4.0-43
------------------
object file name: a.out
Reading symbolic information ...done
(ladebug)

If you do not remember how to start debugging type help, a customized tutorial is displayed depending on the debugger in use.

Before starting the debug operation, we must set a breakpoint, otherwise the program will execute up to end or signal. The debugger always knows the main function, therefore a valid breakpoint is stop in main, but for a meaningful breakpoint we must look at the listing either in the source code window or with the list command. Usually the starting commands will be the ones listed in the Starting Debug Table.

When setting breakpoints, a very common error consists in dropping the at or in flags of the stop command. In such case the debugger interpretes the command as a variable or constant monitoring requests. ladebug does not print error messages but it heavily slowed down setting variable monitor breakpoints. dbx is much faster and prints the messages listed below.

(dbx) stop 3
This command will attempt to watch a constant!
[2] stop ifchanged 3
(dbx) stop k
[3] stop ifchanged K in tst

The message printed by ladebug are:

Reading symbolic information ...done
(ladebug) stop 3
[#1: stop if 3 changes ]
(ladebug) stop k
[#2: stop if k changes ]

Starting Debug
(dbx) list	list source code
(dbx) stop at 7	set breakpoint for first stop
(dbx) c	resume execution
program is not active	program not running - debugger MESSAGE
	to start program issue the run command
(dbx) run	run up to breakpoint
tst.f running
[3] stopped at [tst:7]
(dbx) list 6:3	list code at breakpoint
6 do k=1,9
>* 7 a=sqrt(float(k))
8 enddo
dbx) status	check and delete existing breakpoint
[3] stop at "tst.f":7
(dbx) delete 3
(dbx) status
(dbx) stop at 8 if (k=5)	set a conditional break point

In the above example we set a first breakpoint before a do loop, then we begin program execution. We cannot issue the cont command as the program is not executing and the debugger prints a warning. We must first start execution with command run. The program starts and stops when the first breakpoint is reached. Then we list 3 lines in the breakpoint proximity and decide to set a conditional breakpoint. To avoid ambiguities we check and delete the previous breakpoint and set the new conditional one.

When the program error is detetectd and it is possible to correct it on the flight by changing the value of one or more variables, the debugger acrions are usually the one shown in the Terminating Debug Table.

Terminating Debug
(dbx) cont	run until next breakpoint
[2] stopped at [tst:8 ]
(dbx) assign k=6; print k	change and check wrong variable
6
6
(dbx) c	continue program execution
Program terminated normally
(dbx) status	break points are kept
[4] stop if K = 6 at "tst.f":8	after program termination
(dbx) rerun	rerun program for furhter test
(dbx) quit	terminate debugger session

In the above example we suppose that the reason of the wrong results produced by the program was found, and a correction is possible changing the value of the wrong variable with the assign command. We verify the new value and run the program up to the normal completion. As the debugger keeps memory of the breakpoints, we rerun the program in the same conditions. Finally we terminate the debugger session using the quit command.