Re: Debuggers
- From: rocky@xxxxxxxxx (R. Bernstein)
- Date: Tue, 17 Jun 2008 12:18:38 -0400
TheSaint <fc14301589@xxxxxxxxxxx> writes:
On 19:21, venerdì 13 giugno 2008 R. Bernstein wrote:
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.
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.
I mean that after a post-mortem event, the debugger should forget all.
variables and reload the program, which meanwhile could be debugged.
--
Mailsweeper Home : http://it.geocities.com/call_me_not_now/index.html
- References:
- Debuggers
- From: TheSaint
- Re: Debuggers
- From: R. Bernstein
- Re: Debuggers
- From: TheSaint
- Debuggers
- Prev by Date: Re: Numeric type conversions
- Next by Date: text alignment
- Previous by thread: Re: Debuggers
- Next by thread: Checking list by using of exception
- Index(es):
Relevant Pages
|
