New submission from Mark Shannon <m...@hotpy.org>:
Should the tp_version overflow, and wrap around to a value previously used in the opcache for LOAD_ATTR, then LOAD_ATTR could produce the wrong value. It will take a fair bit of contrivance and a long time to do this, but it is possible: Run some code ~2000 times to get the version cached. Change an attibute of the type about 4 billion times. Rerun the original code. Invalidating all the opcaches is going to be a huge pain, so I propose not allowing the version to overflow but partitioning the 32 bit space something like this: Top 20 bits: Unique per-class ID, 0 and 0xFFFFF are reserved. Low 12 bits: Per-class version. tp_version == 0 that no version has been assigned to this class, as yet. (tp_version & 0xFFF) == 0 means that the version tag is temporarily invalid tp_version == 0xFFFFFFFF means that the version tag is permanently invalid If (tp_version & 0xFFF) != 0 and tp_version != 0xFFFFFFFF, then the combined 32 bits represents a unique tag of the class's state as it does now. Should the low bits of a class hit 0xFFF then all 32 bits are set to 0xFFFFFFFF, and we can't cache its version any more. If a class has been changed a 1000 times, then there is unlikely to be much value in caching it anyway. ---------- components: Interpreter Core messages: 394442 nosy: Mark.Shannon, pablogsal priority: normal severity: normal stage: needs patch status: open title: Incorrect behavior of LOAD_ATTR due to overflow in tp_version type: behavior versions: Python 3.10, Python 3.9 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44240> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
