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: frame->f_lasti not always correct
Type: Stage:
Components: Interpreter Core Versions: Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: jpe, nnorwitz, rhettinger
Priority: normal Keywords:

Created on 2006-01-18 21:57 by jpe, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg27305 - (view) Author: John Ehresman (jpe) * Date: 2006-01-18 21:57
Contrary to the comment in ceval.c, the f_lasti field
is not always correct because it is not updated by the
PREDICT / PREDICTED macros.  This means that when a
GET_ITER is followed by a FOR_ITER, f_lasti will be
left at the index of the GET_ITER the first time
FOR_ITER is executed.  I don't think this is a problem
for YIELD_VALUE because it's not predicted to follow
any other opcode.

I'm running into this when examining bytecode in
calling frames within a debugger callback.

I suggest either documenting that f_lasti may be
incorrect or adjusting it in the PREDICTED macro.
msg27306 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-01-19 05:32
Logged In: YES 
user_id=33168

Raymond?  Given that PREDICTED was added for performance, I
would lean toward updating the doc.  I didn't look at the
code, but I'm pretty sure John's description is accurate.
msg27307 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2007-01-06 01:17
Expanded comment in rev 53285.

IMO, the f->f_lasti is not incorrect.  In effect, a successful prediction links the opcodes so that two codes function as a single new code (GET_ITER, FOR_ITER) -->  GET_ITER_FOR_ITER.
History
Date User Action Args
2022-04-11 14:56:15adminsetgithub: 42806
2006-01-18 21:57:20jpecreate