[issue38115] Invalid bytecode offsets in co_lnotab

Gregory P. Smith added the comment: thanks Thomas! -- resolution: -> fixed stage: patch review -> commit review status: open -> closed ___ Python tracker ___

[issue38115] Invalid bytecode offsets in co_lnotab

Gregory P. Smith added the comment: New changeset 36c6fa968016a46a39c3cdbd0a17ea5490dfa343 by Gregory P. Smith in branch '3.8': bpo-38115: Deal with invalid bytecode offsets in lnotab (GH-16079) (GH-16464) https://github.com/python/cpython/commit/36c6fa968016a46a39c3cdbd0a17ea5490dfa343

[issue38115] Invalid bytecode offsets in co_lnotab

Change by Gregory P. Smith : -- pull_requests: +16049 pull_request: https://github.com/python/cpython/pull/16464 ___ Python tracker ___

[issue38115] Invalid bytecode offsets in co_lnotab

Gregory P. Smith added the comment: New changeset c8165036f374cd2ee64d4314eeb2514f7acb5026 by Gregory P. Smith (T. Wouters) in branch 'master': bpo-38115: Deal with invalid bytecode offsets in lnotab (GH-16079) https://github.com/python/cpython/commit/c8165036f374cd2ee64d4314eeb2514f7acb5026

[issue38115] Invalid bytecode offsets in co_lnotab

Thomas Wouters added the comment: Setting Py_SIZE of the bytes object is possible, but gross and not how you're supposed to operate on bytes. I'm also not entirely convinced lnotab isn't reused in ways it shouldn't. The peephole optimizer already does gross things and is tied very

[issue38115] Invalid bytecode offsets in co_lnotab

Serhiy Storchaka added the comment: Since we modify the content of the bytes object in any case, we can shrink it in-place by setting its Py_SIZE(). But it would be better to fill the end of it with "no-op" fillers. -- ___ Python tracker

[issue38115] Invalid bytecode offsets in co_lnotab

Change by Thomas Wouters : -- keywords: +patch pull_requests: +15701 pull_request: https://github.com/python/cpython/pull/16079 ___ Python tracker ___

[issue38115] Invalid bytecode offsets in co_lnotab

Thomas Wouters added the comment: As mentioned in the PR (GH-15970), I don't think we should fix this bug. We can, but it involves replacing PyCode_Optimize() (which is public but undocumented, with confusing refcount effects) with a stub, and very careful surgery on the code of the

[issue38115] Invalid bytecode offsets in co_lnotab

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38115] Invalid bytecode offsets in co_lnotab

Change by Thomas Wouters : -- pull_requests: +15603 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15970 ___ Python tracker ___

[issue38115] Invalid bytecode offsets in co_lnotab

Thomas Wouters added the comment: There's also a bug where the optimizer may bail out on optimizing a code object *after* updating the lnotab (the last 'goto exitUnchanged' in Python/peephole.c). That bug has existed since Python 3.6, but it's not clear to me how much this actually affects.

[issue38115] Invalid bytecode offsets in co_lnotab

New submission from Thomas Wouters : The peephole optimizer in Python 2.7 and later (and probably a *lot* earlier) has a bug where if the optimizer entirely optimizes away the last line(s) of a function, the lnotab references invalid bytecode offsets: >>> def f(cond1, cond2): ... while