Debugging
Debugging is the process of finding and resolving defects or problems within a computer
program that prevent correct operation of computer software or a system. Debugging tactics
can involve interactive debugging, control flow analysis, unit testing, integration testing, log
file analysis, monitoring at the application or system level, memory dumps, and profiling.
Debugging Process
So the process of using the debugger involves
• setting breakpoints
• stepping through the source code one line at a time
• inspecting the values of variables as they change
• making corrections to the source as bugs are found
• rerunning the program to make sure the fixes are correct
Debugging under IDLE
IDLE has a debugger built into it. It is very useful for stepping through a program and
watching the variables change values.
In the Shell window, click on the Debug menu option at the top and then on Debugger. You
will see a “Debug Control” window like this
Notice that the Shell shows “[DEBUG ON]”.
Explanations of a few other things in the Debug Control window
• Over means that if the statement to be executed has a function call in it, go off and do
the function call without showing any details of the execution or variables, then return
and give the human control again, “step over the function”
• Out assumes you are in some function’s code, finish execution of the function at
normal speed, return from the function and then give the human control again, “step
out of the function”
• Quit stops the execution of the entire program
For the debugger to be most useful, you need to set a breakpoint in your source code before
you start running the program. A breakpoint is a marker on your code that tells the debugger
“run to this point at normal speed, then pause and let the human have control”. You can have
many of them; in more complex programs you would need them at different places. RIGHT
click on a line of your source and choose “set breakpoint”.
The background of the line you click on turns yellow to show the line marked with the
breakpoint.
If you don’t put any breakpoints in your source, when you run it with the debugger on, it will
pause at the first line of executable code (may be an import statement or a call to main()) but
then will run your program normally (i.e. with no pauses).
Now run the program with F5 as usual.
Note that the Debug Control window is opened and that the blue line states that the line “from
math import pi” is ready to be executed (the 7 is for line number 7 in the source file).
From this point you can click the Go button near the top of the window. This will make the
program run at normal speed until a breakpoint is encountered (or input is requested or the
program finishes). You can also use the Step button to step through your code, one line at a
time. This button is used quite a lot. If the line being stepped through has a function call,
execution will go to the first line of the function definition (you are “stepping into” the
function). If the line being stepped through doesn’t have a function call, the line is executed.
In either case, then control goes back to the human.
When you execute a line that has input in it, the debugger seems to shut down but it has not.
If you bring up the Shell window you can see that the program is waiting for input. Make
sure your cursor is in the right place on the window and give it some input and press Enter as
usual.
There are several things to note about this picture. The Shell window is in the background, it
shows that the user entered 23 and pressed Enter. The Debug Control window shows that
execution has moved on to the next line of code. Also, at the bottom of that window there is a
pane that says “Locals” and it shows the value of radius to be ’23’. This is useful in several
ways. It shows the values of variables as they change, and it shows the types of variables.
Note that the value of radius has quotes around it. This means that it is a string value.
Click the Step button again.
Note that the new variable height has been created and has a value of ’14’.
Click the Step button again.
Notice that there is an error in the run of the program at this point (the yellow bar in the
Debug Control window). The interpreter is saying that it cannot multiply “sequence by nonint of type ‘float’”. What it means is that the two input variables are of the wrong type to be
combined with numeric types. This has to be corrected before any more debugging takes
place. This is fixed by using the eval function in the two input statements.
“You can only toggle the debugger when idle” If you get this message in a window when you
try to turn the debugger on, try clicking on the Quit button in the Debug Control window. If
that does not help, try shutting down the program file and reopening it. If that does not help,
shut down Python completely and restart it from scratch.
Note that the bugs in the input statements have been fixed with the addition of “eval”. The
breakpoint was put in again. Breakpoint locations are not saved with the program; they have
to be set again for every debugging session.
Note the type of the Local variables in this image. They don’t have the quotes around the
values any more! They are numbers now.
As you step through the program one statement at a time, you can see more variables get
values. When we come to the next bug you can see that the variable Pi is not the same as the
variable pi, which is defined in the math library. This bug would need to be fixed, then the
debugging would continue.
AssignmentTutorOnline
Another Option:
The module pdb defines an interactive source code debugger for Python programs. It
supports setting (conditional) breakpoints and single stepping at the source line level,
inspection of stack frames, source code listing, and evaluation of arbitrary Python code
in the context of any stack frame. It also supports post-mortem debugging and can be
called under program control.
The debugger is extensible — it is actually defined as the class Pdb. This is currently
undocumented but easily understood by reading the source. The extension interface
uses the modules bdb and cmd.
The debugger’s prompt is (Pdb). Typical usage to run a program under control of the
debugger is:
>>> import pdb
>>> import mymodule
>>> pdb.run(‘mymodule.test()’)
> (0)?()
(Pdb) continue
> (1)?()
(Pdb) continue
NameError: ‘spam’
> (1)?()
(Pdb)
pdb.py can also be invoked as a script to debug other scripts. For example:
python -m pdb myscript.py
The typical usage to break into the debugger from a running program is to insert
import pdb; pdb.set_trace()
There are a few commands we can use with pdb are as follows.
Some useful ones to remember are:
• b: set a breakpoint
• c: continue debugging until you hit a breakpoint
• s: step through the code
• n: to go to next line of code
• l: list source code for the current file (default: 11 lines including the line being
executed)
• u: navigate up a stack frame
• d: navigate down a stack frame
• p: to print the value of an expression in the current context