blob: e393118ec757b70fa63290f90b5db3ecb3c1622a [file] [log] [blame]
Guido van Rossumdc46c7f1995-03-01 15:38:16 +00001\section{Standard module \sectcode{pdb}}
2\stmodindex{pdb}
3\index{debugging}
4
5This module defines an interactive source code debugger for Python
6programs. It supports breakpoints and single stepping at the source
7line level, inspection of stack frames, source code listing, and
8evaluation of arbitrary Python code in the context of any stack frame.
9It also supports post-mortem debugging and can be called under program
10control.
11
12The debugger is extensible --- it is actually defined as a class
13\code{Pdb}. The extension interface uses the (also undocumented)
14modules \code{bdb} and \code{cmd}; it is currently undocumented.
15\ttindex{Pdb}
16\ttindex{bdb}
17\ttindex{cmd}
18
19A primitive windowing version of the debugger also exists --- this is
20module \code{wdb}, which requires STDWIN.
21\index{stdwin}
22\ttindex{wdb}
23
24Typical usage to run a program under control of the debugger is:
25
26\begin{verbatim}
27>>> import pdb
28>>> import mymodule
29>>> pdb.run('mymodule.test()')
30(Pdb)
31\end{verbatim}
32
33Typical usage to inspect a crashed program is:
34
35\begin{verbatim}
36>>> import pdb
37>>> import mymodule
38>>> mymodule.test()
39(crashes with a stack trace)
40>>> pdb.pm()
41(Pdb)
42\end{verbatim}
43
44The debugger's prompt is ``\code{(Pdb) }''.
45
46The module defines the following functions; each enters the debugger
47in a slightly different way:
48
49\begin{funcdesc}{run}{statement\optional{\, globals\optional{\, locals}}}
50Execute the \var{statement} (which should be a string) under debugger
51control. The debugger prompt appears before any code is executed; you
52can set breakpoint and type \code{continue}, or you can step through
53the statement using \code{step} or \code{next}. The optional
54\var{globals} and \var{locals} arguments specify the environment in
55which the code is executed; by default the dictionary of the module
56\code{__main__} is used. (See the explanation of the \code{exec}
57statement or the \code{eval()} built-in function.)
58\end{funcdesc}
59
60\begin{funcdesc}{runeval}{expression\optional{\, globals\optional{\, locals}}}
61Evaluate the \var{expression} (which should be a string) under
62debugger control. When \code{runeval()} returns, it returns the value
63of the expression. Otherwise this function is similar to
64\code{run()}.
65\end{funcdesc}
66
67\begin{funcdesc}{runcall}{function\optional{\, argument\, ...}}
68Call the \var{function} (which should be a callable Python object, not
69a string) with the given arguments. When \code{runcall()} returns, it
70returns the return value of the function call. The debugger prompt
71appears as soon as the function is entered.
72\end{funcdesc}
73
74\begin{funcdesc}{set_trace}{}
75Enter the debugger at the calling stack frame. This is useful to
76hard-code a breakpoint at a given point in code, even if the code is
77not otherwise being debugged.
78\end{funcdesc}
79
80\begin{funcdesc}{post_mortem}{traceback}
81Enter post-mortem debugging of the given \var{traceback} object.
82\end{funcdesc}
83
84\begin{funcdesc}{pm}{}
85Enter post-mortem debugging based on the traceback found in
86\code{sys.last_traceback}.
87\end{funcdesc}
88
89\subsection{Debugger Commands}
90
91The debugger recognizes the following commands. Most commands can be
92abbreviated to one or two letters; e.g. ``\code{h(elp)}'' means that
93either ``\code{h}'' or ``\code{help}'' can be used to enter the help
94command (but not ``\code{he}'' or ``\code{hel}'', nor ``\code{H}'' or
95``\code{Help} or ``\code{HELP}''). Arguments to commands must be
96separated by whitespace (spaces or tabs). Optional arguments are
97enclosed in square brackets (``\code{[]}'')in the command syntax; the
98square brackets must not be typed. Alternatives in the command syntax
99are separated by a vertical bar (``\code{|}'').
100
101Entering a blank line repeats the last command entered. Exception: if
102the last command was a ``\code{list}'' command, the next 11 lines are
103listed.
104
105Commands that the debugger doesn't recognize are assumed to be Python
106statements and are executed in the context of the program being
107debugged. Python statements can also be prefixed with an exclamation
108point (``\code{!}''). This is a powerful way to inspect the program
109being debugged; it is even possible to change variables. When an
110exception occurs in such a statement, the exception name is printed
111but the debugger's state is not changed.
112
113\begin{description}
114
115\item[{h(elp) [\var{command}]}]
116
117Without argument, print the list of available commands.
118With a \var{command} as argument, print help about that command.
119``\code{help pdb}'' displays the full documentation file; if the
120environment variable \code{PAGER} is defined, the file is piped
121through that command instead. Since the var{command} argument must be
122an identifier, ``\code{help exec}'' gives help on the ``\code{!}''
123command.
124
125\item[{w(here)}]
126
127Print a stack trace, with the most recent frame at the bottom.
128An arrow indicates the current frame, which determines the
129context of most commands.
130
131\item[{d(own)}]
132
133Move the current frame one level down in the stack trace
134(to an older frame).
135
136\item[{u(p)}]
137
138Move the current frame one level up in the stack trace
139(to a newer frame).
140
141\item[{b(reak) [\var{lineno} \code{|} \var{function}]}]
142
143With a \var{lineno} argument, set a break there in the current
144file. With a \var{function} argument, set a break at the entry of
145that function. Without argument, list all breaks.
146
147\item[{cl(ear) [lineno]}]
148
149With a \var{lineno} argument, clear that break in the current file.
150Without argument, clear all breaks (but first ask confirmation).
151
152\item[{s(tep)}]
153
154Execute the current line, stop at the first possible occasion
155(either in a function that is called or on the next line in the
156current function).
157
158\item[{n(ext)}]
159
160Continue execution until the next line in the current function
161is reached or it returns. (The difference between \code{next} and
162\code{step} is that \code{step} stops inside a called function, while
163\code{next} executes called functions at full speed, only stopping at
164the next line in the current function.)
165
166\item[{r(eturn)}]
167
168Continue execution until the current function returns.
169
170\item[{c(ont(inue))}]
171
172Continue execution, only stop when a breakpoint is encountered.
173
174\item[{l(ist) [\var{first} [, \var{last}]]}]
175
176List source code for the current file.
177Without arguments, list 11 lines around the current line
178or continue the previous listing.
179With one argument, list 11 lines around at that line.
180With two arguments, list the given range;
181if the second argument is less than the first, it is a count.
182
183\item[{a(rgs)}]
184
185Print the argument list of the current function.
186
187\item[{p \var{expression}}]
188
189Evaluate the \var{expression} in the current context and print its
190value.
191
192\item[{[!] \var{statement}}]
193
194Execute the (one-line) \var{statement} in the context of
195the current stack frame.
196The exclamation point can be omitted unless the first word
197of the statement resembles a debugger command.
198To set a global variable, you can prefix the assignment
199command with a ``\code{global}'' command on the same line, e.g.:
200\begin{verbatim}
201(Pdb) global list_options; list_options = ['-l']
202(Pdb)
203\end{verbatim}
204
205\item[{q(uit)}]
206
207Quit from the debugger.
208The program being executed is aborted.
209
210\end{description}