Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 1 | \chapter{The Python Debugger} |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 2 | \stmodindex{pdb} |
| 3 | \index{debugging} |
| 4 | |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 5 | \renewcommand{\indexsubitem}{(in module pdb)} |
| 6 | |
| 7 | The module \code{pdb} defines an interactive source code debugger for |
| 8 | Python programs. It supports setting breakpoints and single stepping |
| 9 | at the source line level, inspection of stack frames, source code |
| 10 | listing, and evaluation of arbitrary Python code in the context of any |
| 11 | stack frame. It also supports post-mortem debugging and can be called |
| 12 | under program control. |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 13 | |
| 14 | The debugger is extensible --- it is actually defined as a class |
Guido van Rossum | 25f6fcc | 1995-04-04 12:28:53 +0000 | [diff] [blame] | 15 | \code{Pdb}. This is currently undocumented but easily understood by |
| 16 | reading the source. The extension interface uses the (also |
| 17 | undocumented) modules \code{bdb} and \code{cmd}. |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 18 | \ttindex{Pdb} |
| 19 | \ttindex{bdb} |
| 20 | \ttindex{cmd} |
| 21 | |
| 22 | A primitive windowing version of the debugger also exists --- this is |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 23 | module \code{wdb}, which requires STDWIN (see the chapter on STDWIN |
| 24 | specific modules). |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 25 | \index{stdwin} |
| 26 | \ttindex{wdb} |
| 27 | |
Guido van Rossum | 25f6fcc | 1995-04-04 12:28:53 +0000 | [diff] [blame] | 28 | The debugger's prompt is ``\code{(Pdb) }''. |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 29 | Typical usage to run a program under control of the debugger is: |
| 30 | |
| 31 | \begin{verbatim} |
| 32 | >>> import pdb |
| 33 | >>> import mymodule |
| 34 | >>> pdb.run('mymodule.test()') |
Guido van Rossum | 25f6fcc | 1995-04-04 12:28:53 +0000 | [diff] [blame] | 35 | > <string>(0)?() |
| 36 | (Pdb) continue |
| 37 | > <string>(1)?() |
| 38 | (Pdb) continue |
| 39 | NameError: 'spam' |
| 40 | > <string>(1)?() |
| 41 | (Pdb) |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 42 | \end{verbatim} |
| 43 | |
Guido van Rossum | 809408e | 1997-06-02 17:28:16 +0000 | [diff] [blame] | 44 | \code{pdb.py} can also be invoked as |
| 45 | a script to debug other scripts. For example: |
| 46 | \code{python /usr/local/lib/python1.4/pdb.py myscript.py} |
| 47 | |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 48 | Typical usage to inspect a crashed program is: |
| 49 | |
| 50 | \begin{verbatim} |
| 51 | >>> import pdb |
| 52 | >>> import mymodule |
| 53 | >>> mymodule.test() |
Guido van Rossum | 25f6fcc | 1995-04-04 12:28:53 +0000 | [diff] [blame] | 54 | Traceback (innermost last): |
| 55 | File "<stdin>", line 1, in ? |
| 56 | File "./mymodule.py", line 4, in test |
| 57 | test2() |
| 58 | File "./mymodule.py", line 3, in test2 |
| 59 | print spam |
| 60 | NameError: spam |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 61 | >>> pdb.pm() |
Guido van Rossum | 25f6fcc | 1995-04-04 12:28:53 +0000 | [diff] [blame] | 62 | > ./mymodule.py(3)test2() |
| 63 | -> print spam |
| 64 | (Pdb) |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 65 | \end{verbatim} |
| 66 | |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 67 | The module defines the following functions; each enters the debugger |
| 68 | in a slightly different way: |
| 69 | |
| 70 | \begin{funcdesc}{run}{statement\optional{\, globals\optional{\, locals}}} |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 71 | Execute the \var{statement} (given as a string) under debugger |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 72 | control. The debugger prompt appears before any code is executed; you |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 73 | can set breakpoints and type \code{continue}, or you can step through |
| 74 | the statement using \code{step} or \code{next} (all these commands are |
| 75 | explained below). The optional \var{globals} and \var{locals} |
| 76 | arguments specify the environment in which the code is executed; by |
| 77 | default the dictionary of the module \code{__main__} is used. (See |
| 78 | the explanation of the \code{exec} statement or the \code{eval()} |
| 79 | built-in function.) |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 80 | \end{funcdesc} |
| 81 | |
| 82 | \begin{funcdesc}{runeval}{expression\optional{\, globals\optional{\, locals}}} |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 83 | Evaluate the \var{expression} (given as a a string) under debugger |
| 84 | control. When \code{runeval()} returns, it returns the value of the |
| 85 | expression. Otherwise this function is similar to |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 86 | \code{run()}. |
| 87 | \end{funcdesc} |
| 88 | |
| 89 | \begin{funcdesc}{runcall}{function\optional{\, argument\, ...}} |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 90 | Call the \var{function} (a function or method object, not a string) |
| 91 | with the given arguments. When \code{runcall()} returns, it returns |
| 92 | whatever the function call returned. The debugger prompt appears as |
| 93 | soon as the function is entered. |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 94 | \end{funcdesc} |
| 95 | |
| 96 | \begin{funcdesc}{set_trace}{} |
| 97 | Enter the debugger at the calling stack frame. This is useful to |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 98 | hard-code a breakpoint at a given point in a program, even if the code |
| 99 | is not otherwise being debugged (e.g. when an assertion fails). |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 100 | \end{funcdesc} |
| 101 | |
| 102 | \begin{funcdesc}{post_mortem}{traceback} |
| 103 | Enter post-mortem debugging of the given \var{traceback} object. |
| 104 | \end{funcdesc} |
| 105 | |
| 106 | \begin{funcdesc}{pm}{} |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 107 | Enter post-mortem debugging of the traceback found in |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 108 | \code{sys.last_traceback}. |
| 109 | \end{funcdesc} |
| 110 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 111 | \section{Debugger Commands} |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 112 | |
| 113 | The debugger recognizes the following commands. Most commands can be |
| 114 | abbreviated to one or two letters; e.g. ``\code{h(elp)}'' means that |
| 115 | either ``\code{h}'' or ``\code{help}'' can be used to enter the help |
| 116 | command (but not ``\code{he}'' or ``\code{hel}'', nor ``\code{H}'' or |
| 117 | ``\code{Help} or ``\code{HELP}''). Arguments to commands must be |
| 118 | separated by whitespace (spaces or tabs). Optional arguments are |
Guido van Rossum | 6c4f003 | 1995-03-07 10:14:09 +0000 | [diff] [blame] | 119 | enclosed in square brackets (``\code{[]}'') in the command syntax; the |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 120 | square brackets must not be typed. Alternatives in the command syntax |
| 121 | are separated by a vertical bar (``\code{|}''). |
| 122 | |
| 123 | Entering a blank line repeats the last command entered. Exception: if |
| 124 | the last command was a ``\code{list}'' command, the next 11 lines are |
| 125 | listed. |
| 126 | |
| 127 | Commands that the debugger doesn't recognize are assumed to be Python |
| 128 | statements and are executed in the context of the program being |
| 129 | debugged. Python statements can also be prefixed with an exclamation |
| 130 | point (``\code{!}''). This is a powerful way to inspect the program |
Guido van Rossum | 25f6fcc | 1995-04-04 12:28:53 +0000 | [diff] [blame] | 131 | being debugged; it is even possible to change a variable or call a |
| 132 | function. When an |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 133 | exception occurs in such a statement, the exception name is printed |
| 134 | but the debugger's state is not changed. |
| 135 | |
| 136 | \begin{description} |
| 137 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 138 | \item[h(elp) [\var{command}]] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 139 | |
| 140 | Without argument, print the list of available commands. |
| 141 | With a \var{command} as argument, print help about that command. |
| 142 | ``\code{help pdb}'' displays the full documentation file; if the |
| 143 | environment variable \code{PAGER} is defined, the file is piped |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 144 | through that command instead. Since the \var{command} argument must be |
| 145 | an identifier, ``\code{help exec}'' must be entered to get help on the |
| 146 | ``\code{!}'' command. |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 147 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 148 | \item[w(here)] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 149 | |
| 150 | Print a stack trace, with the most recent frame at the bottom. |
| 151 | An arrow indicates the current frame, which determines the |
| 152 | context of most commands. |
| 153 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 154 | \item[d(own)] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 155 | |
| 156 | Move the current frame one level down in the stack trace |
| 157 | (to an older frame). |
| 158 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 159 | \item[u(p)] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 160 | |
| 161 | Move the current frame one level up in the stack trace |
| 162 | (to a newer frame). |
| 163 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 164 | \item[b(reak) [\var{lineno}\code{|}\var{function}]] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 165 | |
| 166 | With a \var{lineno} argument, set a break there in the current |
| 167 | file. With a \var{function} argument, set a break at the entry of |
| 168 | that function. Without argument, list all breaks. |
| 169 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 170 | \item[cl(ear) [\var{lineno}]] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 171 | |
| 172 | With a \var{lineno} argument, clear that break in the current file. |
| 173 | Without argument, clear all breaks (but first ask confirmation). |
| 174 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 175 | \item[s(tep)] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 176 | |
| 177 | Execute the current line, stop at the first possible occasion |
| 178 | (either in a function that is called or on the next line in the |
| 179 | current function). |
| 180 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 181 | \item[n(ext)] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 182 | |
| 183 | Continue execution until the next line in the current function |
| 184 | is reached or it returns. (The difference between \code{next} and |
| 185 | \code{step} is that \code{step} stops inside a called function, while |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 186 | \code{next} executes called functions at (nearly) full speed, only |
| 187 | stopping at the next line in the current function.) |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 188 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 189 | \item[r(eturn)] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 190 | |
| 191 | Continue execution until the current function returns. |
| 192 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 193 | \item[c(ont(inue))] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 194 | |
| 195 | Continue execution, only stop when a breakpoint is encountered. |
| 196 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 197 | \item[l(ist) [\var{first} [, \var{last}]]] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 198 | |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 199 | List source code for the current file. Without arguments, list 11 |
| 200 | lines around the current line or continue the previous listing. With |
| 201 | one argument, list 11 lines around at that line. With two arguments, |
| 202 | list the given range; if the second argument is less than the first, |
| 203 | it is interpreted as a count. |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 204 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 205 | \item[a(rgs)] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 206 | |
| 207 | Print the argument list of the current function. |
| 208 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 209 | \item[p \var{expression}] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 210 | |
| 211 | Evaluate the \var{expression} in the current context and print its |
Guido van Rossum | f4aac48 | 1995-03-02 12:37:55 +0000 | [diff] [blame] | 212 | value. (Note: \code{print} can also be used, but is not a debugger |
| 213 | command --- this executes the Python \code{print} statement.) |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 214 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 215 | \item[[!] \var{statement}] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 216 | |
| 217 | Execute the (one-line) \var{statement} in the context of |
| 218 | the current stack frame. |
| 219 | The exclamation point can be omitted unless the first word |
| 220 | of the statement resembles a debugger command. |
| 221 | To set a global variable, you can prefix the assignment |
| 222 | command with a ``\code{global}'' command on the same line, e.g.: |
| 223 | \begin{verbatim} |
| 224 | (Pdb) global list_options; list_options = ['-l'] |
| 225 | (Pdb) |
| 226 | \end{verbatim} |
| 227 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 228 | \item[q(uit)] |
Guido van Rossum | dc46c7f | 1995-03-01 15:38:16 +0000 | [diff] [blame] | 229 | |
| 230 | Quit from the debugger. |
| 231 | The program being executed is aborted. |
| 232 | |
| 233 | \end{description} |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 234 | |
| 235 | \section{How It Works} |
| 236 | |
| 237 | Some changes were made to the interpreter: |
| 238 | |
| 239 | \begin{itemize} |
| 240 | \item sys.settrace(func) sets the global trace function |
| 241 | \item there can also a local trace function (see later) |
| 242 | \end{itemize} |
| 243 | |
| 244 | Trace functions have three arguments: (\var{frame}, \var{event}, \var{arg}) |
| 245 | |
| 246 | \begin{description} |
| 247 | |
| 248 | \item[\var{frame}] is the current stack frame |
| 249 | |
| 250 | \item[\var{event}] is a string: \code{'call'}, \code{'line'}, \code{'return'} |
| 251 | or \code{'exception'} |
| 252 | |
| 253 | \item[\var{arg}] is dependent on the event type |
| 254 | |
| 255 | \end{description} |
| 256 | |
| 257 | A trace function should return a new trace function or None. |
| 258 | Class methods are accepted (and most useful!) as trace methods. |
| 259 | |
| 260 | The events have the following meaning: |
| 261 | |
| 262 | \begin{description} |
| 263 | |
| 264 | \item[\code{'call'}] |
| 265 | A function is called (or some other code block entered). The global |
| 266 | trace function is called; arg is the argument list to the function; |
| 267 | the return value specifies the local trace function. |
| 268 | |
| 269 | \item[\code{'line'}] |
| 270 | The interpreter is about to execute a new line of code (sometimes |
| 271 | multiple line events on one line exist). The local trace function is |
| 272 | called; arg in None; the return value specifies the new local trace |
| 273 | function. |
| 274 | |
| 275 | \item[\code{'return'}] |
| 276 | A function (or other code block) is about to return. The local trace |
| 277 | function is called; arg is the value that will be returned. The trace |
| 278 | function's return value is ignored. |
| 279 | |
| 280 | \item[\code{'exception'}] |
| 281 | An exception has occurred. The local trace function is called; arg is |
| 282 | a triple (exception, value, traceback); the return value specifies the |
| 283 | new local trace function |
| 284 | |
| 285 | \end{description} |
| 286 | |
| 287 | Note that as an exception is propagated down the chain of callers, an |
| 288 | \code{'exception'} event is generated at each level. |
| 289 | |
| 290 | Stack frame objects have the following read-only attributes: |
| 291 | |
| 292 | \begin{description} |
| 293 | \item[f_code] the code object being executed |
| 294 | \item[f_lineno] the current line number (\code{-1} for \code{'call'} events) |
| 295 | \item[f_back] the stack frame of the caller, or None |
| 296 | \item[f_locals] dictionary containing local name bindings |
| 297 | \item[f_globals] dictionary containing global name bindings |
| 298 | \end{description} |
| 299 | |
| 300 | Code objects have the following read-only attributes: |
| 301 | |
| 302 | \begin{description} |
| 303 | \item[co_code] the code string |
| 304 | \item[co_names] the list of names used by the code |
| 305 | \item[co_consts] the list of (literal) constants used by the code |
| 306 | \item[co_filename] the filename from which the code was compiled |
| 307 | \end{description} |