[ python-Bugs-1689458 ] pdb unable to jump to first statement
SourceForge.net
noreply at sourceforge.net
Mon Apr 2 02:07:32 CEST 2007
Bugs item #1689458, was opened at 2007-03-27 16:07
Message generated for change (Comment added) made by gotgenes
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Lasher (gotgenes)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb unable to jump to first statement
Initial Comment:
The Python debugger is unable to "jump" back to the first executable statement in a frame once that statement has been executed. For example:
chris at feathers:~/development/playground$ python -m pdb simple.py
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) next
> /home/chris/development/playground/simple.py(4)?()
-> b = 2
(Pdb) jump 3
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) list
1 #!/usr/bin/env python
2
3 a = 1
4 -> b = 2
5
6 c = a + b
7
8 print c
[EOF]
(Pdb) next
> /home/chris/development/playground/simple.py(6)?()
-> c = a + b
One can see that after supposedly "jump"ing to line 3 at the second command, when "list"ing the line, the debugger is actually at line 4. The "next" command further demonstrates this since it re-executes line 4 and moves to line 6.
This issue was raised on comp.lang.python. (For example, see
<http://groups.google.com/group/comp.lang.python/browse_thread/thread/7960201616873f41/e9623c08e3618051>
or if that link is munged, refer to
<http://tinyurl.com/324feu>
Duncan Booth offers the following:
[quote]
I verified (with a print statement in pdb) that assigning to self.curframe.f_lineno sets self.curframe.f_lineno and sel.curframe.f_lasti incorrectly
...
The problem looks to be in frameobject.c:
addr = 0;
line = f->f_code->co_firstlineno;
new_lasti = -1;
for (offset = 0; offset < lnotab_len; offset += 2) {
addr += lnotab[offset];
line += lnotab[offset+1];
if (line >= new_lineno) {
new_lasti = addr;
new_lineno = line;
break;
}
}
The first bytes in lnotab are the length and line increment for line 3 (i.e. 6, 1). If line==f->f_code->co_firstlineno it should set new_lasti=0, new_lineno=line but the loop still executes once which increments new_lasti and new_lineno to the next line (6, 4).
[/quote]
And Rocky Bernstein offers the following:
[quote]
Best as I can tell, it looks like a bug in Python. pdb, pydb, rpdb2 all handle the "jump" command by changing the frame f_lineno value. When the corresponding code pointer has offset 0 (or equivalently and more simlply as you put it, is the first statement) this doesn't seem to work properly.
[/quote]
----------------------------------------------------------------------
>Comment By: Chris Lasher (gotgenes)
Date: 2007-04-01 19:07
Message:
Logged In: YES
user_id=1180453
Originator: YES
File Added: jumpbug2.py
----------------------------------------------------------------------
Comment By: Chris Lasher (gotgenes)
Date: 2007-04-01 19:06
Message:
Logged In: YES
user_id=1180453
Originator: YES
File Added: jumpbug.py
----------------------------------------------------------------------
Comment By: Chris Lasher (gotgenes)
Date: 2007-04-01 18:53
Message:
Logged In: YES
user_id=1180453
Originator: YES
I'm changing the category. Apparently this is a bug in the Python core,
itself, not pdb.
>From Rocky Bernstein on comp.lang.python
[quote]
At present it looks like the bug is in Python, and its handling after
setting the current frame's f_lineno when it refers to byte code offset 0,
not pdb.
[/quote]
----------------------------------------------------------------------
Comment By: Rocky Bernstein (rockyb)
Date: 2007-03-31 05:32
Message:
Logged In: YES
user_id=158581
Originator: NO
Although a single file unit test would be nice, below is a short simple
program that I think clearly shows the bug. Alas, as a follow-up comment I
don't see a way to attach files so I have to paste it inline. However with
this example and the information from Duncan Booth, I think the problem and
how to fix it is pretty clear.
file: jumpbug.py
#!/usr/bin/env python
import inspect, linecache, sys
def tracer(frame, event, arg):
global z
(filename, line_no) = inspect.getframeinfo(frame)[0:2]
print "Event %s at line %d:" % (event, line_no)
print "\t", linecache.getline(filename, line_no),
print "----------------------"
try:
if z == 0:
if line_no == 4:
print "***We jumped back to line 4 but should have gone to
2**"
sys.exit(1)
frame.f_lineno = 2 # And 3 is broken too.
except NameError:
pass
return tracer # This helps emacs figure indentation out
sys.settrace(tracer)
execfile("jumpbug2.py")
#END first file
file jumpbug2.py:
#!/usr/bin/env python
x = 2 # This statement gets skipped the 2nd time around
q = 1 # This statement gets skipped too!
try: # tracer() will exit here if z == 0 and line_no == 4
y = z
except NameError:
z = 0
print "When tracing via tracer(), f_lineno will be set to 2 here."
print "You should never get here when tracing"
file jumpbug2.py:
----------------------------------------------------------------------
Comment By: Chris Lasher (gotgenes)
Date: 2007-03-28 20:24
Message:
Logged In: YES
user_id=1180453
Originator: YES
Truthfully, I don't have enough know-how to write a full test case or a
patch. I have put forth a request on the comp.lang.python thread (link in
original report) for those that would to please do so.
----------------------------------------------------------------------
Comment By: Collin Winter (collinwinter)
Date: 2007-03-28 16:54
Message:
Logged In: YES
user_id=1344176
Originator: NO
Could you work up a full test case for this? Or better yet, a patch?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470
More information about the Python-bugs-list
mailing list