[Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
noreply@sourceforge.net
noreply@sourceforge.net
Mon, 27 May 2002 16:44:47 -0700
Bugs item #210682, was opened at 2000-07-31 23:14
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470
Category: Python Library
Group: None
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb can only step when at botframe (PR#4)
Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows
[Resubmitted by GvR]
It is a problem that bugged me for _ages_. Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)
The problem is simply: when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works. A "continue" command
functions as a step until you start debugging a frame below self.botframe.
It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.
The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.
My solution was this: instead of run() calling "exec" directly, it calls
another internal function. This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly. Then
stop_here is modified accordingly.
The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.
Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.
Thanks,
Mark.
====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999 guido moved from incoming to open
----------------------------------------------------------------------
>Comment By: Christian Tismer (tismer)
Date: 2002-05-28 01:44
Message:
Logged In: YES
user_id=105700
# test program for bdb buglet.
# usage:
# import pdb, bdbtest
# pdb.runcall(bdbtest.test)
#
# then, in the debugger, type "b 13":
def test():
a=0
a=1
a=2
a=3
a=4
a=5
a=6
a=7
a=8
a=9
# the breakpoint will be at "a=4"
# now try to continue with "c", and you
# will see it still single stepping.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-27 19:11
Message:
Logged In: YES
user_id=6380
Can you be more specific in your example?
I don't understand how I start a 10-line
program with runcall, since runcall requires
a function.
I also want to know exactly which syntax
you use to set the breakpoint.
----------------------------------------------------------------------
Comment By: Christian Tismer (tismer)
Date: 2002-05-26 10:58
Message:
Logged In: YES
user_id=105700
Ok, I didn't check ti in, but I disagree to close it!
Do you think I would supply a patch if there weren't a problem?
The problem was reported to me by an IronPort Python
user who simply had the problem that pdb.runcall
on a given function *does not* run, but always single steps.
Your test doesn't get at the problem, since you don't set a
breakpoint, which is necessary to make it show up!
Here we go:
- write a simple program with some 10 lines
- start it with runcall
- set a breakpoint
- continue
and it will definately step!
With my patch, it works as expected.
Furthermore, Mark's F5 command is documented to
"start the program in the debugger". It never did so.
With the patch, it does.
Let's bring it to the end it deserves.
regards - chris
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-25 13:56
Message:
Logged In: YES
user_id=6380
OK, closing. Christian: please *don't* check it it!
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2002-05-25 06:17
Message:
Logged In: YES
user_id=14198
This appears to have been fixed magically in Python 2.2.
Using Python 2.1 with the sample demonstrates the bug, while
2.2 and current CVS both work correctly. Haven't tried 2.1.1
A scan of the pdb and bdb logs don't show an obvious
candidate that fixed the bug, but to be quite honest, I
don't care *how* it was fixed now that it is <wink>
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 21:36
Message:
Logged In: YES
user_id=6380
You know, I cannot reproduce the problem!
I created this module:
import pdb
def foo():
x = 12
y = 2
z = x**y
print z
return
pdb.set_trace()
print 12
print "hello world"
foo()
When I run it I get the pdb prompt.
When I hit "continue" at the prompt,
the whole program executes.
Before we start messing with this
I'd like to be able to reproduce
the problem so I can confirm that
it goes away!
----------------------------------------------------------------------
Comment By: Christian Tismer (tismer)
Date: 2002-05-23 22:55
Message:
Logged In: YES
user_id=105700
There appears to be a simple solution.
I'm not used to pdb very much, so I cannot fur sure
say that my patch doesn't affect any extension of it,
but it seems to work just fine.
Idea: Allow botframe not to be a frame at all, but also None.
This makes it possible to use f_back in line 67:
self.botframe = frame.f_back ##!!CT
In stop_here, we just omit the first two lines:
def stop_here(self, frame):
##!!CT if self.stopframe is None:
##!!CT return 1
if frame is self.stopframe:
return 1
while frame is not None and frame is not self.stopframe:
if frame is self.botframe:
return 1
frame = frame.f_back
return 0
By this trick, botframe is llowed to be one level "on top"
of the
topmost frame, and we see the topmost frame behave as nicely
as every other.
-- chris
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 23:55
Message:
Logged In: YES
user_id=6380
Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.
----------------------------------------------------------------------
Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:30
Message:
Logged In: YES
user_id=31392
Is this really a bug? Or just a feature request? Perhaps
we should move it to 42 and close the report.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 16:19
Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 16:18
Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging. Instead of doing a runcall for my function I do a runcall on debug.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470