pyunwind: measure code-object offsets for CPython 3.13 and 3.14 (#83) - #132
Merged
Conversation
Only 3.12 had them, so 3.13 and 3.14 silently rendered python:0x… -- and Fedora's system interpreter is 3.14, which means the default Python on a common distribution got no names at all from the change that added them. Measured with offsetof against each version's own headers. All three carry the same values (co_filename=112, co_name=120, co_qualname=128, co_firstlineno=68), and that agreement is a hazard as much as a convenience: a bug returning 3.12's table for every version would be invisible in the numbers. So each was measured separately, and each is verified end to end against a LIVE interpreter of that version -- the live test now runs per version rather than against whichever one it found first, because a single-version test would pass just as happily on the broken table. Validated on four interpreters, including Fedora's system 3.14.3, which is a different build from the 3.14.7 the offsets were taken from: all resolve Widget.method_here at target.py:4. An unsupported version still declines rather than borrowing a neighbour's table. Reading co_qualname at the wrong offset yields a pointer to something that is not a string, and the frame would be named from whatever it found; asserted, so a future version added to the frame table without measuring its code layout cannot quietly inherit one.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Only 3.12 had measured code-object offsets, so 3.13 and 3.14 silently rendered
python:0x…— and Fedora's system interpreter is 3.14, so the default Python on a common distribution got no names at all from the change that added them.Measured with
offsetofagainst each version's own headers (obtained withuv python install, no system packages needed).The values agree, and that is a hazard
All three carry the same offsets —
co_filename=112,co_name=120,co_qualname=128,co_firstlineno=68.A bug returning 3.12's table for every version would therefore be invisible in the numbers. So each was measured separately against its own headers, and the live test now runs per version rather than against whichever interpreter it found first — a single-version test would pass just as happily on the broken table.
Verified against real interpreters
Widget.method_hereattarget.py:4That last row is the one that matters: it shows the layout is a property of the CPython version rather than of the particular build the headers came from.
Still declines what it has not measured
An unsupported version gets no code offsets rather than a neighbour's table. Reading
co_qualnameat the wrong offset yields a pointer to something that is not a string, and the frame would be named from whatever it found — asserted, so a future version added to the frame table without measuring its code layout cannot quietly inherit one.