A breakpoint makes your program stop at that
point. You can set breakpoints with the break
command and its
variants. You can specify the place where your program should stop by
file and line number or by function name.
The debugger assigns a number to each breakpoint when you create it; these numbers are successive integers starting with 1. In many of the commands for controlling various features of breakpoints you use this number. Each breakpoint may be enabled or disabled; if disabled, it has no effect on your program until you enable it again.
The debugger allows you to set any number of breakpoints at the same place in your program. There is nothing unusual about this because different breakpoints can have different conditions associated with them.
The simplest sort of breakpoint breaks every time your program reaches a specified place. You can also specify a condition for a breakpoint. A condition is just a Boolean expression in your programming language. A breakpoint with a condition evaluates the expression each time your program reaches it, and your program stops only if the condition is true.
This is the converse of using assertions for program validation; in that situation, you want to stop when the assertion is violated-that is, when the condition is false.
Break conditions can have side effects, and may even call functions in
your program. This can be useful, for example, to activate functions
that log program progress, or to use your own print functions to
format special data structures. The effects are completely predictable
unless there is another enabled breakpoint at the same address. (In
that case, pydb
might see the other breakpoint first and stop your
program without checking the condition of this one.) Note that
breakpoint commands are usually more convenient and flexible than break
conditions for the
purpose of performing side effects when a breakpoint is reached.
Break conditions can be specified when a breakpoint is set, by adding
a comma in the arguments to the break
command. They can also be
changed at any time with the condition
command.
|
function[, condition]]
With a lineno argument, set a break at that line number in the
current file. With a function argument, set a break at the
first executable statement within that function. The line number may
be prefixed with a filename and a colon to specify a breakpoint in
another file (probably one that hasn't been loaded yet). The file is
searched on sys.path
. Note that each breakpoint is assigned a
number to which all the other breakpoint commands refer.
If a second argument is present, it is an expression which must evaluate to true before the breakpoint is honored.
Without an argument, a breakpoint is set at the current location.
Note that this is a different behavior from pdb
(but the same
behavior as gdb
).
If threading is enabled, you can also specify a thread name. See 1.2.14.
|
function[, condition]]
Temporary breakpoint, which is removed automatically when it is
first hit. The arguments are the same as those for break
.
If threading is enabled, you can also specify a thread name. See 1.2.14.
|
function]Clear breakpoint at specified line or function. Argument may be line number, function name, or `*' and an address. If a line number is specified, all breakpoints in that line are cleared. If a function is specified, the breakpoints at the beginning of the function are cleared. If an address is specified, breakpoints at that address are cleared.
With no argument, clears all breakpoints in the line where the selected frame is executing.
See also the delete
command below which clears breakpoints by
number. Note that delete
handles some cases that were
previously handled by pdb
's clear
command.
Set commands to be executed when a breakpoint is hit. Give breakpoint number as the argument after "commands". With no bpnumber argument, commands refers to the last one set. The commands themselves follow starting on the next line. Type a line containing "end" to terminate the commands.
Here's an example:
(Pydb) break gcd Breakpoint 1 set in file gcd.py, line 24. (Pydb) commands Type commands for when breakpoint 1 is hit, one per line. End with a line saying just "end". >info locals >end (Pydb) c a = 3 b = 5 (gcd.py:28): gcd 28 if a > b: (Pydb) c a = 2 b = 3 (gcd.py:28): gcd 28 if a > b: (Pydb)
To remove all commands from a breakpoint, type commands and
follow it immediately with end
; that is, give no commands.
Specifying any command resuming execution (currently continue
,
step
, next
, return
, jump
, skip
, and
quit
) terminates the command list as if that command was
immediately followed by end
. This is because any time you
resume execution (even with a simple next or step), you may encounter
another breakpoint--which could have its own command list, leading to
ambiguities about which list to execute.
If you use the silent
command in the command list, the
usual message about stopping at a breakpoint is not printed.
This may be desirable for breakpoints that are to print a
specific message and then continue. If none of the other
commands print anything, you see no sign that the breakpoint
was reached.
With a space-separated list of breakpoint numbers, clear those breakpoints. Without argument, clear all breaks (but first ask confirmation).
Disable the breakpoints given as a space-separated list of breakpoint numbers. Disabling a breakpoint means it cannot cause the program to stop execution, but unlike clearing a breakpoint, it remains in the list of breakpoints and can be (re-)enabled.
Enable the breakpoints specified.
Set the ignore count for the given breakpoint number. If count is omitted, the ignore count is set to 0. A breakpoint becomes active when the ignore count is zero. When non-zero, the count is decremented each time the breakpoint is reached, the breakpoint is not disabled, and any associated condition evaluates to true.
Condition is an expression which must evaluate to true before the breakpoint is honored. If condition is absent, any existing condition is removed; i.e., the breakpoint is made unconditional.
See About this document... for information on suggesting changes.