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

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.

Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

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.

Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

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

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!

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>

Logged In: YES 
user_id=6380

OK, closing.  Christian: please *don't* check it it!

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

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.

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.

Logged In: YES 
user_id=6380

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. :-)

Logged In: YES 
user_id=33168

Checked in as bdb.py 1.38/1.39 for current (fixed whitespace), 
1.33.6.2 for 2.2
1.31.2.1 for 2.1

Hopefully I got it right.  Closing.