In gdb, the "frame" command with no arguments prints the current stack frame. Is it intended to have a similar usage in pydb?
My trials so far have shown the following behaviour:
pydb 1.22-3 (the version distributed with Ubuntu Hardy Heron), causes an internal error:
prw@ceiriog:kitware$ pydb MyImageViewer3.py
(/home/prw/src/kitware/MyImageViewer3.py:1): <module>
1 from kwwidgets import *
(Pydb) b 12
Breakpoint 1 set in file /home/prw/src/kitware/MyImageViewer3.py, line 12.
(Pydb) c
(/home/prw/src/kitware/MyImageViewer3.py:12): getbounds
12 xmin = 99999999
(Pydb) frame
Traceback (most recent call last):
File "/usr/bin/pydb", line 656, in main
p._runscript(mainpyfile)
File "/usr/share/python-support/pydb/pydb/pydbcmd.py", line 74, in _runscript
self.run(statement, globals=globals_, locals=locals_)
File "/usr/share/python-support/pydb/pydb/pydbbdb.py", line 305, in run
exec cmd in globals, locals
File "<string>", line 1, in <module>
File "MyImageViewer3.py", line 35, in <module>
bb = getbounds("/home/prw/tmp/map")
File "MyImageViewer3.py", line 12, in getbounds
xmin = 99999999
File "MyImageViewer3.py", line 12, in getbounds
xmin = 99999999
File "/usr/lib/python2.5/bdb.py", line 48, in trace_dispatch
return self.dispatch_line(frame)
File "/usr/lib/python2.5/bdb.py", line 66, in dispatch_line
self.user_line(frame)
File "/usr/share/python-support/pydb/pydb/pydbbdb.py", line 401, in user_line
self.interaction(frame, None)
File "/usr/share/python-support/pydb/pydb/gdb.py", line 450, in interaction
self.cmdloop()
File "/usr/lib/python2.5/cmd.py", line 142, in cmdloop
stop = self.onecmd(line)
File "/usr/share/python-support/pydb/pydb/pydbcmd.py", line 456, in onecmd
return cmd.Cmd.onecmd(self, line)
File "/usr/lib/python2.5/cmd.py", line 219, in onecmd
return func(arg)
File "/usr/share/python-support/pydb/pydb/gdb.py", line 1238, in do_frame
" Got: %s") % arg)
File "/usr/share/python-support/pydb/pydb/pydbcmd.py", line 246, in get_an_int
return ret_value
UnboundLocalError: local variable 'ret_value' referenced before assignment
*** Uncaught exception. Entering post mortem debugging
*** Running 'c' or 'step' will restart the program
(/usr/bin/pydb:704): main
704 p.interaction(t.tb_frame,t)
(Pydb)
In pydb-1.23, frame (with no arguments) prints nothing at all.
This has implications for the Backtrace dialog in DDD... I can't get it to work quite right...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Version 1.22 seems to that bug which version 1.23 doesn't. In all released including 1.23 the frame number is not optional. Alas pydb doesn't print an error message when none is given, and that's a but. So in 1.23 use '0'.
But since gdb *does* allow the frame number to be optional and since we *do* want to follow gdb behavior (except there's good reason not to), I've just committed a change in pydb CVS to follow what gdb does.
As for getting a more recent version of pydb in Debian, I'll contact the Debian maintainer, Alex, to see what he wants to do. It may be that there will be another pydb release to clear out some lingering bugs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In gdb, the "frame" command with no arguments prints the current stack frame. Is it intended to have a similar usage in pydb?
My trials so far have shown the following behaviour:
pydb 1.22-3 (the version distributed with Ubuntu Hardy Heron), causes an internal error:
prw@ceiriog:kitware$ pydb MyImageViewer3.py
(/home/prw/src/kitware/MyImageViewer3.py:1): <module>
1 from kwwidgets import *
(Pydb) b 12
Breakpoint 1 set in file /home/prw/src/kitware/MyImageViewer3.py, line 12.
(Pydb) c
(/home/prw/src/kitware/MyImageViewer3.py:12): getbounds
12 xmin = 99999999
(Pydb) frame
Traceback (most recent call last):
File "/usr/bin/pydb", line 656, in main
p._runscript(mainpyfile)
File "/usr/share/python-support/pydb/pydb/pydbcmd.py", line 74, in _runscript
self.run(statement, globals=globals_, locals=locals_)
File "/usr/share/python-support/pydb/pydb/pydbbdb.py", line 305, in run
exec cmd in globals, locals
File "<string>", line 1, in <module>
File "MyImageViewer3.py", line 35, in <module>
bb = getbounds("/home/prw/tmp/map")
File "MyImageViewer3.py", line 12, in getbounds
xmin = 99999999
File "MyImageViewer3.py", line 12, in getbounds
xmin = 99999999
File "/usr/lib/python2.5/bdb.py", line 48, in trace_dispatch
return self.dispatch_line(frame)
File "/usr/lib/python2.5/bdb.py", line 66, in dispatch_line
self.user_line(frame)
File "/usr/share/python-support/pydb/pydb/pydbbdb.py", line 401, in user_line
self.interaction(frame, None)
File "/usr/share/python-support/pydb/pydb/gdb.py", line 450, in interaction
self.cmdloop()
File "/usr/lib/python2.5/cmd.py", line 142, in cmdloop
stop = self.onecmd(line)
File "/usr/share/python-support/pydb/pydb/pydbcmd.py", line 456, in onecmd
return cmd.Cmd.onecmd(self, line)
File "/usr/lib/python2.5/cmd.py", line 219, in onecmd
return func(arg)
File "/usr/share/python-support/pydb/pydb/gdb.py", line 1238, in do_frame
" Got: %s") % arg)
File "/usr/share/python-support/pydb/pydb/pydbcmd.py", line 246, in get_an_int
return ret_value
UnboundLocalError: local variable 'ret_value' referenced before assignment
*** Uncaught exception. Entering post mortem debugging
*** Running 'c' or 'step' will restart the program
(/usr/bin/pydb:704): main
704 p.interaction(t.tb_frame,t)
(Pydb)
In pydb-1.23, frame (with no arguments) prints nothing at all.
This has implications for the Backtrace dialog in DDD... I can't get it to work quite right...
Version 1.22 seems to that bug which version 1.23 doesn't. In all released including 1.23 the frame number is not optional. Alas pydb doesn't print an error message when none is given, and that's a but. So in 1.23 use '0'.
But since gdb *does* allow the frame number to be optional and since we *do* want to follow gdb behavior (except there's good reason not to), I've just committed a change in pydb CVS to follow what gdb does.
As for getting a more recent version of pydb in Debian, I'll contact the Debian maintainer, Alex, to see what he wants to do. It may be that there will be another pydb release to clear out some lingering bugs.