Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gh-101696: Make sure immutable types have a valid version tag #101742

Closed
wants to merge 1 commit into from

Conversation

erlend-aasland
Copy link
Contributor

@erlend-aasland erlend-aasland commented Feb 9, 2023

@erlend-aasland
Copy link
Contributor Author

cc. @markshannon @kumaraditya303

@erlend-aasland
Copy link
Contributor Author

I guess we can skip NEWS, as this is strictly internal.

@erlend-aasland erlend-aasland marked this pull request as ready for review February 9, 2023 17:13
@erlend-aasland erlend-aasland requested review from ericsnowcurrently and removed request for markshannon February 9, 2023 17:14
@kumaraditya303
Copy link
Contributor

I'll review this by tomorrow.

Copy link
Member

@ericsnowcurrently ericsnowcurrently left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

FWIW, it would be nice if there were a test that covered the original problem from gh-101696 (i.e. fail without the fix and pass with it), whether by crashing or some other means. Would you mind adding something like that in this PR.

Comment on lines +232 to +237
if (_PyType_HasFeature(type, Py_TPFLAGS_VALID_VERSION_TAG)) {
CHECK(type->tp_version_tag != 0);
}
else {
CHECK(type->tp_version_tag == 0);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check is worth adding, regardless of the rest of this PR, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Comment on lines +6979 to +6983
/* All immutable types must have a static valid version tag */
if (type->tp_flags & Py_TPFLAGS_IMMUTABLETYPE) {
type->tp_version_tag = next_version_tag++;
type->tp_flags |= Py_TPFLAGS_VALID_VERSION_TAG;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tl;dr I'm on board with this.

As I mentioned in gh-101696, this is good as it covers non-builtin static types (AKA non-_Py_TPFLAGS_STATIC_BUILTIN), e.g. in community extension modules. 1 (The switch to Py_TPFLAGS_IMMUTABLETYPE seems fine.)

FWIW, the already merged fix may fit a little better with the vague idea (in my head) that we should be special-casing static types in the runtime as little as possible (or otherwise in more explicit ways, like the dedicated _PyStaticType_Dealloc()). In that spirit, rather than modifying PyType_Ready(), I was going to suggest we could find a way to apply _PyStaticType_Dealloc() to all static types, not just the builtin ones, which might be a good idea regardless. However, that feels like overkill for fixing this issue. Plus, we're already special-casing static types here in PyType_Ready(). (Perhaps my mental model is misaligned...)

Bottom line: dropping the original fix and adding the fix you have here is worth it since it handles non-builtin static types too.

Footnotes

  1. One could argue that non-builtin (non-core) static types should be discouraged (basically, they already are) and we shouldn't bother adding extra maintenance burden--however small--to accommodate them. However, that's not where the community is at nor will be for a long time and there's no reason to be so hard-line about it, especially in a case like this where the additional maintenance burden is essentially zero.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this PR does not special-case static types; the condition is for immutable types.

@bedevere-bot
Copy link

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

And if you don't make the requested changes, you will be put in the comfy chair!

@erlend-aasland
Copy link
Contributor Author

erlend-aasland commented Feb 9, 2023

it would be nice if there were a test that covered the original problem from gh-101696 (i.e. fail without the fix and pass with it), whether by crashing or some other means. Would you mind adding something like that in this PR.

The original problem was uncovered by test_finalize_structseq in test_embed in gh-101304. Without Kumar's fix (d9de079), that particular test segfaulted. With Kumar's fix applied, the test passed; with Kumar's fix reverted and this PR applied, the test also passes.

I could of course try to add a more deterministic test. I'm not quite sure how to provoke that ATM, but I can look into it.

@erlend-aasland
Copy link
Contributor Author

Closing, as per discussion on the issue.

@erlend-aasland erlend-aasland deleted the versiontag branch February 10, 2023 17:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants