Debuggers

[TheSaint]

Hi,

while testing my program I found some strange happening with pdb and pydb.

I like pydb because let me restart the program and nicer features, but if
errors pop up, then it will forget all variables (globals and locals gone).
I've to go for pdb because it isn't affected by that problem, but also in
some case pdb doesn't recognize a fix after a post-mortem restart. The funny
thing is that it shows the line corrected, but pdb execute the one it put in
memory.
However, I think also python shell has such flaw. I'd like to know how to
blank all current data and restart a program or re-import a corrected class
sentence.
Any other to try?
I'm also prone to use Ipython, but I still miss some learning how to run a
program within Ipython itself.
So if I do:

import myprogram
myprogram.__main__

Will it run? And then the other arguments from CLI, how do I pass them in?
--
Mailsweeper Home : http://it.geocities.com/call_me_not_now/index.html

 

[R. Bernstein]

Hi,

while testing my program I found some strange happening with pdb and pydb.

I like pydb because let me restart the program and nicer features, but if
errors pop up, then it will forget all variables (globals and locals gone).

I'm not completely sure what you mean, but I gather that in
post-mortem debugging you'd like to inspect local variables defined at the
place of error. For example in this program

def raise_error:
x=5
raise FloatingPointError

raise_error

you'd like to look at x.

Python as a language is a little different than say Ruby. In Python
the handler for the exception is called *after* the stack is unwound
while in Ruby it is called before. What this means to you is basically
what you reported: that you are not going to be able to see some local
variables after an exception occurs (i.e. in post-mortem debugging)
whether pydb, pdb, any debugger or any Python program you write.

This was mentioned a while back:
http://groups.google.com/group/comp...d/b0b1908495dde7bc?lnk=st&q=#b0b1908495dde7bc

By the way, although Ruby *does* call the exception handler before the
stack is unwound, there's no way that I know to *clear* the exception
so that you can dynamically "handle" it. This has a certain legitimacy
since it might be dangerous to continue in some exception and the
state of the interpreter may be inconsistent. For example if I write

x = 1/0

or
if 1/0 > 5 :

what value do I use for 1/0? (Far worse is where something like a SEGV
occurs, but I'm not sure that will raise an exception instead of
terminate Python.)

 

[TheSaint]

I'm not completely sure what you mean, but I gather that in
post-mortem debugging you'd like to inspect local variables defined at the
place of error.

Yes, exactly. This can be seen with pdb, but not pydb.
If I'm testing a piece of code and it breaks, then I'd like to see the
variables and find which of them doesn't go as expected.

Python as a language is a little different than say Ruby. In Python
the handler for the exception is called *after* the stack is unwound

I'm not doing comparison with other languages. I'm simply curious to know why
pydb don't keep variables like pdb.

Final, I agreed the idea to restart the debugger when an exception is trow.
It could be feasible to let reload the file and restart. Some time I can
re-run the program , as the error is fixed, but sometime pdb doesn't
recognize the corrections applied.
I mean that after a post-mortem event, the debugger should forget all
variables and reload the program, which meanwhile could be debugged.

 

[R. Bernstein]

Yes, exactly. This can be seen with pdb, but not pydb.
If I'm testing a piece of code and it breaks, then I'd like to see the
variables and find which of them doesn't go as expected.


I'm not doing comparison with other languages. I'm simply curious to know why
pydb don't keep variables like pdb.

If you are simply curious, then a guess is that the frame from the
traceback (t) isn't set by pydb's post_mortem method in calling the
Pdb interaction() method, whereas it does get set in the corresponding
pdb post_mortem code.

It's possible this is a bug -- it's all in the details. But if it is a
bug or a feature improvement, probably a better place to to request a
change would be in the tracker for the pydb project:

http://sourceforge.net/tracker/?group_id=61395

Should you go this route, I'd suggest giving the smallest program and
scenario that exhibits the problem but also has a different behavior
in pdb. There are programming interfaces to post-mortem debugging in
pdb and pydb, namely post_mortem() and pm(); so best is a short self
contained program that when run sets up as much of this as possible.

And if the bug is accepted and fixed such a short-self contained
program would get turned into a test case and incluide to the set
regression tests normally run.

Final, I agreed the idea to restart the debugger when an exception is trow.
It could be feasible to let reload the file and restart. Some time I can
re-run the program , as the error is fixed, but sometime pdb doesn't
recognize the corrections applied.

The restart that I submitted as a patch to pdb two and a half years
ago is what I call a "warm" restart: no Python code is actually
reloaded. The reason ti was done way is that is a simple way to
maintain the debugger settings such as breakpoints; also it requires
saving less knowledge about how the program was initially run so it
might be applicable in more contexts.

The down side though, in addition to what you've noticed with regards
to files which have changed, is that global state may be different
going into the program when it is restarted.

In the last pydb release, 1.23 a "save" command was added to so that
breakpoints and other debugger state could be saved across debug
sessions which includes a "cold" or "exec" restart.