[Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken

SourceForge.net noreply@sourceforge.net
Mon, 28 Apr 2003 13:57:37 -0700


Bugs item #708901, was opened at 2003-03-24 12:09
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Michael Hudson (mwh)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-04-28 16:57

Message:
Logged In: YES 
user_id=31435

Well, this one's a mess.  The patch changes debugger 
behavior in that it no longer stops on the 'for' each time 
around the loop.  I had better luck leaving the com_set_lineno
() call where it is now, but changing its second argument 
instead, like so:

	com_set_lineno(c, c->c_last_line);

Then it stops on the "for" each time around the loop, but 
pointing at the last line of the "for" (in your whittled example, 
on the line ending with "10):").  Better than nothing.

Unfortunately, the encoding of lnotab assumes that line 
numbers and byte offsets are presented in monotonically non-
decreasing order.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 18:38

Message:
Logged In: YES 
user_id=33168

The patch worked for me on Linux, after I removed
httplib.pyc. :-)
Does it jump to the right line in the debugger whe iterating
through a loop?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 12:43

Message:
Logged In: YES 
user_id=6656

Stupid minimal testcase:

def f():
    for res in range(1,
                     10):
        pass

Tim, you've looked at compile.c today <wink>, can you check
the attached patch?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 12:36

Message:
Logged In: YES 
user_id=6656

Waddya know, it's not my fault.

For some reason, something is trying to store a negative
line_incr into the c_lnotab which gets masked into a line
increment of 255.  Fun.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 12:16

Message:
Logged In: YES 
user_id=6656

yow!  probably my fault.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470