| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
@Yhg1s I think this fix should be backported to 3.12. |
Sorry, something went wrong.
There was a problem hiding this comment.
lgtm! we're going to want to backport to 3.12!
Sorry, something went wrong.
|
Closing and re-opening to retrigger CLA checks. Sorry for the noise. |
Sorry, something went wrong.
|
Thanks @carljm for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12. |
Sorry, something went wrong.
|
GH-107876 is a backport of this pull request to the 3.12 branch. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
The type watcher implementation adds char tp_watched; to the PyTypeObject struct, and then in PyType_Modified it assigns int bits = type->tp_watched; and then treats bits as a bitset, expecting that only the low 8 bits should ever be set.
On platforms where char is signed (e.g. x86), if the top bit in tp_watched is set, the cast to int bits will sign-extend with 1s, and we will thus have a lot of high bits set in bits that are not supposed to ever be set.
On x86 in a debug build, without the fix in this PR, the new test hits the assertion in PyType_Modified that only bit positions < TYPE_MAX_WATCHERS should be set, and aborts.
The fix is simple: tp_watched should be defined as unsigned char so that it is zero-extended, not sign-extended.
Note that the test is carefully designed to not assume there are no type watchers already active. It doesn't attempt to register a fixed number of type watchers, instead it just registers type watchers until it reaches TYPE_MAX_WATCHERS - 1, the last available slot and the one that can trigger this bug (since it will set the highest bit in tp_watched when watching a type.)