This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: pdb can only step when at botframe (PR#4)
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: tismer Nosy List: gvanrossum, jhylton, mhammond, nnorwitz, nobody, tismer
Priority: normal Keywords:

Created on 2000-07-31 21:14 by anonymous, last changed 2022-04-10 16:02 by admin. This issue is now closed.

File name Uploaded Description Edit tismer, 2002-05-23 20:57 modified by CT to support normal behavior of the topmost frame. tismer, 2002-05-27 23:44 Test code and instructions how to reproduce the buglet.
Messages (14)
msg401 - (view) Author: Nobody/Anonymous (nobody) Date: 2000-07-31 21:14
Jitterbug-Id: 4
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

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.



Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open
msg402 - (view) Author: Nobody/Anonymous (nobody) Date: 2000-10-17 14:18
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.
msg403 - (view) Author: Nobody/Anonymous (nobody) Date: 2000-10-17 14:19
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
msg404 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2002-03-01 22:30
Logged In: YES 

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.
msg405 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-03-01 22:55
Logged In: YES 

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.
msg406 - (view) Author: Christian Tismer (old) (tismer) Date: 2002-05-23 20:55
Logged In: YES 

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
msg407 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-05-24 19:36
Logged In: YES 

You know, I cannot reproduce the problem!

I created this module:

import pdb
def foo():
    x = 12
    y = 2
    z = x**y
    print z
print 12
print "hello world"

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!
msg408 - (view) Author: Mark Hammond (mhammond) * (Python committer) Date: 2002-05-25 04:17
Logged In: YES 

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>
msg409 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-05-25 11:56
Logged In: YES 

OK, closing.  Christian: please *don't* check it it!
msg410 - (view) Author: Christian Tismer (old) (tismer) Date: 2002-05-26 08:58
Logged In: YES 

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
msg411 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-05-27 17:11
Logged In: YES 

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.
msg412 - (view) Author: Christian Tismer (old) (tismer) Date: 2002-05-27 23:44
Logged In: YES 

# test program for bdb buglet.
# usage:
# import pdb, bdbtest
# pdb.runcall(bdbtest.test)
# then, in the debugger, type "b 13":

def test():

# the breakpoint will be at "a=4"
# now try to continue with "c", and you
# will see it still single stepping.
msg413 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-05-28 00:53
Logged In: YES 

OK, you convinced me.  Do you want to check it in or should
I do it?  If you want to do it, go ahead, and mark it as a
2.1 and 2.2 bugfix candidate.

And thanks for this solution!  (I tried this in IDLE, and
there's a benign effect there, too. :-)
msg414 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2002-05-29 01:33
Logged In: YES 

Checked in as 1.38/1.39 for current (fixed whitespace), for 2.2 for 2.1

Hopefully I got it right.  Closing.
Date User Action Args
2022-04-10 16:02:11adminsetgithub: 32752
2000-07-31 21:14:21anonymouscreate