It is also to possible enter the debugger after a crash or traceback
even though the program was not started via pydb
. This is
called post-mortem debugging.
Basically all you do is import pydb
(if that hasn't been done
already), and call pydb.pm()
.
To make this more concrete we will give an example. We have the
following text mymodule.py
def test(): print spam
Now here's a sample session
>>> import mymodule >>> mymodule.test() Traceback (most recent call last): File "<stdin>", line 1, in ? File "mymodule.py", line 2, in test print spam NameError: global name 'spam' is not defined >>> import pydb >>> pydb.pm() (/home/src/external-cvs/pydb/test/mymodule.py:2): test (Pydb) where -> 0 test() called from file '/tmp/mymodule.py' at line 2 ## 1 in file '<stdin>' at line 1 (Pydb) list 1 def test(): 2 -> print spam [EOF] (Pydb) quit >>>
At present if you are using ipython
, that captures the
exception and sys.last_traceback
will not be defined.
If you have a traceback stored say in variable t
, instead of
pydb.pm()
above, use pydb.post_mortem(t)
.
When invoked as a script, pydb
will automatically enter
post-mortem debugging if the program being debugged exits
abnormally. After post-mortem debugging (or after normal exit of the
program), pydb
will restart the program. Automatic restarting
preserves pydb
's state (such as breakpoints) and in most cases is more
useful than quitting the debugger upon the program's exit.
See About this document... for information on suggesting changes.