[ python-Bugs-711268 ] A large block of commands after an "
if" cannot be
SourceForge.net
noreply at sourceforge.net
Sun Jan 2 01:33:12 CET 2005
Bugs item #711268, was opened at 2003-03-28 04:47
Message generated for change (Comment added) made by jepler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
Summary: A large block of commands after an "if" cannot be
Initial Comment:
A Generated Python script Contains the code:
if 1:
file = bugreport.vim
... long list of commands ....
Executing this code with:
exec cmds in globals(), globals()
Results in the error:
SystemError: com_backpatch: offset too large
Looking into the code for com_backpatch() it appears
that the code is more than what can be jumped over.
Possible solutions:
1. When there is too much code, use another jump
statement that allows for a larger offset.
2. Always use a jump statement with a large offset
3. When "if 1" is used, don't generate a jump
statement (not a real fix, but works for the situation
where I ran into the bug).
It looks like this bug exists in all versions of Python.
----------------------------------------------------------------------
Comment By: Jeff Epler (jepler)
Date: 2005-01-01 18:33
Message:
Logged In: YES
user_id=2772
Please see my (unsuitable for inclusion) patch at
http://mail.python.org/pipermail/python-list/2004-November/249827.html
I think that message suggests some steps that might result
in an acceptable patch.
----------------------------------------------------------------------
Comment By: Facundo Batista (facundobatista)
Date: 2004-12-27 10:10
Message:
Logged In: YES
user_id=752496
Also happens in 2.4.
I'm reopening the bug, in group 2.4.
----------------------------------------------------------------------
Comment By: Bram Moolenaar (vimboss)
Date: 2004-12-27 10:04
Message:
Logged In: YES
user_id=57665
It appears between Python 2.2 and 2.3 the efficiency of the
produced bytecode was improved. You now need to repeat the
command 10923 times to produce the error. Thus the problem
remains, it's just further away.
You can reproduce the problem with this program:
cmds = "if 1:\n"
for i in xrange(1, 10923):
cmds = cmds + " a = 'a'\n"
exec cmds in globals(), globals()
I verified with Python 2.3.3, don't have a newer version
right now.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-12-26 13:11
Message:
Logged In: YES
user_id=357491
I can't reproduce it with 2.3, 2.3 maintenance, 2.4 maintenance, or 2.5 in
CVS using 8000 lines.
Closing as out of date.
----------------------------------------------------------------------
Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 09:00
Message:
Logged In: YES
user_id=752496
Can not reproduce the problem in Py2.3.4 using the method
posted by vimboss. It's already fixed?
----------------------------------------------------------------------
Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 09:00
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
. Facundo
----------------------------------------------------------------------
Comment By: Bram Moolenaar (vimboss)
Date: 2003-03-28 14:03
Message:
Logged In: YES
user_id=57665
I can reproduce the problem with this text:
if 1:
a = "a"
Repeat the assignment 7282 times. Feed this text to "exec".
With 7281 assignments you do not get the error.
Looks like 9 bytes are produced per assignment.
Good luck fixing this!
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 13:18
Message:
Logged In: YES
user_id=6380
Hm, the 32-bit argument doesn't work because of what
backpatch does. It would require a totally different
approach to allow backpatching a larer offset, or we'd
always have to reserve 4 bytes for the offset. :-(
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 13:13
Message:
Logged In: YES
user_id=6380
Just curious. How big was the block of code?
Also, I wonder if the error message is bogus; opcode
arguments can now be 32 bits AFAIK.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470
More information about the Python-bugs-list
mailing list