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.

classification
Title: Long jumps with frame_setlineno
Type: crash Stage: patch review
Components: Interpreter Core Versions: Python 3.0, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: amaury.forgeotdarc Nosy List: amaury.forgeotdarc, fboule, georg.brandl
Priority: normal Keywords: needs review, patch

Created on 2008-12-05 13:05 by fboule, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
frame_setlineno.patch amaury.forgeotdarc, 2008-12-05 14:09
Messages (6)
msg77013 - (view) Author: (fboule) Date: 2008-12-05 13:05
This concerns a known bug in the frame_setlineno() function for Python
2.5.x and 2.6.x (maybe in earlier/later version too). It is not possible
to use this function when the address or line offset in lnotab are
greater than 127. The problem comes from the lnotab variable which is
typed char*, i.e. "signed char*" implicitly. Any value above 127 becomes
a negative number.

The fix is very simple (applied on the Python 2.6.1 version of the
source code):

--- frameobject.c       Thu Oct 02 19:39:50 2008
+++ frameobject_fixed.c Fri Dec 05 11:27:42 2008
@@ -119,8 +119,8 @@
        line = f->f_code->co_firstlineno;
        new_lasti = -1;
        for (offset = 0; offset < lnotab_len; offset += 2) {
-               addr += lnotab[offset];
-               line += lnotab[offset+1];
+               addr += ((unsigned char*)lnotab)[offset];
+               line += ((unsigned char*)lnotab)[offset+1];
                if (line >= new_lineno) {
                        new_lasti = addr;
                        new_lineno = line;
msg77017 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-12-05 14:09
Attached patch is similar (it declares the variable as "unsigned char*")
and adds a test.
msg77022 - (view) Author: (fboule) Date: 2008-12-05 14:45
Is it intended to be applied on Python 2.5.x and/or Python 2.6.x (and
when)? The current Python 2.6.1 release does not have the fix.
msg77025 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-12-05 15:06
Yes, target is 2.6.2 and up, 3.0.1 and up.
msg88135 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-05-20 19:51
I think you can apply this.
msg88682 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-06-01 22:23
Fixed with r73114 (trunk), r73117 (py3k), r73119 (2.6) and r73120 (3.0)
History
Date User Action Args
2022-04-11 14:56:42adminsetgithub: 48797
2009-06-01 22:23:55amaury.forgeotdarcsetstatus: open -> closed
resolution: fixed
messages: + msg88682
2009-05-25 14:01:14amaury.forgeotdarcsetassignee: amaury.forgeotdarc
2009-05-20 19:51:13georg.brandlsetnosy: + georg.brandl
messages: + msg88135
2008-12-05 15:06:43amaury.forgeotdarcsetmessages: + msg77025
versions: + Python 3.0, - Python 2.5, Python 2.5.3
2008-12-05 14:45:32fboulesetmessages: + msg77022
2008-12-05 14:09:06amaury.forgeotdarcsetfiles: + frame_setlineno.patch
keywords: + patch, needs review
messages: + msg77017
nosy: + amaury.forgeotdarc
stage: patch review
2008-12-05 13:05:08fboulecreate