[Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)

[noreply@sourceforge.net]

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: Open
Resolution: Later
Priority: 1
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-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