handling unexpected exceptions in pdb

[Simon Bierbaum]

Hi all,

I'm in an interactive session in pdb, debugging my code using
pdb.runcall. Somewhere, an exception is raised and lands uncaught on
stdout. Is there any way of picking up this exception and at least
read the full message, or even accessing its stack trace to determine
where exactly within the one line I just executed it was raised? This
is where I'm stuck:

/usr/local/apache2/bin/Model/Database.py(287)disconnect()

(Pdb) n
FlushError: FlushErr...perly.",)

/usr/local/apache2/bin/Model/Database.py(287)disconnect()

(Pdb) import sys
(Pdb) sys.last_traceback
*** AttributeError: 'module' object has no attribute 'last_traceback'

Thanks, Simon

[R. Bernstein]

Simon Bierbaum <bi******@vierfalt.comwrites:

Hi all,

I'm in an interactive session in pdb, debugging my code using
pdb.runcall. Somewhere, an exception is raised and lands uncaught on
stdout. Is there any way of picking up this exception and at least
read the full message, or even accessing its stack trace to determine
where exactly within the one line I just executed it was raised? This
is where I'm stuck:

>/usr/local/apache2/bin/Model/Database.py(287)disconnect()

(Pdb) n
FlushError: FlushErr...perly.",)

>/usr/local/apache2/bin/Model/Database.py(287)disconnect()

(Pdb) import sys
(Pdb) sys.last_traceback
*** AttributeError: 'module' object has no attribute 'last_traceback'

Thanks, Simon

I think basically you want runcall to be wrapped in a try block. So in pdb.py
instead of:

def runcall(*args, **kwds):
return Pdb().runcall(*args, **kwds)
Change with:

def runcall(*args, **kwds):
p=Pdb()
try:
return p.runcall(*args, **kwds)
except:
traceback.print_exc()
print "Uncaught exception. Entering post mortem debugging"
t = sys.exc_info()[2]
p.interaction(t.tb_frame,t)
print "Post mortem debugger finished."
return None

Code like this appears near the bottom of the pdb.py file. If that
works, you may want to file a bug Python report to change pdb. Also
note that one may want to do the same thing on run() and runeval()

But also if this does what you want, please file a feature request to pydb:
http://sourceforge.net/tracker/?func...95&atid=497162

and I'll probably make it happen in the next release.

This is the first time I've heard of anyone using runcall.

[Simon Bierbaum]

Am 10.07.2008 um 20:52 schrieb R. Bernstein:

Simon Bierbaum <bi******@vierfalt.comwrites:

>Hi all,

I'm in an interactive session in pdb, debugging my code using
pdb.runcall. Somewhere, an exception is raised and lands uncaught on
stdout. Is there any way of picking up this exception and at least
read the full message, or even accessing its stack trace to determine
where exactly within the one line I just executed it was raised? This
is where I'm stuck:

>>/usr/local/apache2/bin/Model/Database.py(287)disconnect()

(Pdb) n
FlushError: FlushErr...perly.",)

>>/usr/local/apache2/bin/Model/Database.py(287)disconnect()

(Pdb) import sys
(Pdb) sys.last_traceback
*** AttributeError: 'module' object has no attribute 'last_traceback'

Thanks, Simon

I think basically you want runcall to be wrapped in a try block. So
in pdb.py
instead of:

def runcall(*args, **kwds):
return Pdb().runcall(*args, **kwds)
Change with:

def runcall(*args, **kwds):
p=Pdb()
try:
return p.runcall(*args, **kwds)
except:
traceback.print_exc()
print "Uncaught exception. Entering post mortem debugging"
t = sys.exc_info()[2]
p.interaction(t.tb_frame,t)
print "Post mortem debugger finished."
return None

Code like this appears near the bottom of the pdb.py file. If that
works, you may want to file a bug Python report to change pdb. Also
note that one may want to do the same thing on run() and runeval()

But also if this does what you want, please file a feature request
to pydb:
http://sourceforge.net/tracker/?func...95&atid=497162

and I'll probably make it happen in the next release.

This is the first time I've heard of anyone using runcall.

My app is called from mod_python with the PythonEnablePdb option set
to On, which makes mod_python call my handler function not directly,
but wrapped into a pdb.runcall(). I figure I might not be the first
one to use runcall under these circumstances ;-)

I'll definitely give your hack a try, thank you for your help!

Cheers, Simon