-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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-117657: TSAN Fix races in PyMember_Get
and PyMember_Set
, for C extensions
#123211
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quite hard to review since everything looks the same and the functions are not ordered by pairs apparently. I didn't go through everything but I had a question and an observation.
I'm not exactly sure why Anyways, the TSAN checks for |
I've relaunched the test manually (I can't relaunch the SSL test though, I don't know why) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I left a few comments below.
How long do the added tests takes to run?
@colesbury can you take another look? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mostly looks good. Please add a char
test to test_structmembers.py
. I think the implementation in the PR is broken (see inline comment) and it's not caught by any unit test.
It's fine to ping me on PRs like you did here, but please also use GitHub's "re-request review" button (top-right corner, in the reviewers section). It means that the PR shows up in my list of "awaiting reviews".
Sorry, will do. |
Co-authored-by: Sam Gross <[email protected]>
I finally had some time to come back to this. I guess that moving the stores after error checking does slightly change the externally-visible behavior. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
!buildbot nogil |
🤖 New build scheduled with the buildbot fleet by @colesbury for commit 6c5cec5 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
Thanks @dpdani! |
|
|
that sounds like my fault, I'll take a look later today |
|
|
|
|
@dpdani @colesbury: As you can see in previous comments, test_capi fails on multiple buildbots. I'm not sure why. |
mm, I can't seem to reproduce it locally. maybe some platform compatibility issue? what do you usually do in these situations? |
Let's skip the test on s390x for now while we investigate. I'm not sure what's causing the failure. The only thing I can think of is that |
#127577 should fix it. The problem was that the 'C' format code expects an https://docs.python.org/3/c-api/arg.html#c.Py_BuildValue This happens to work out okay on little endian systems because the non-zero part of the value is at the same place (the first byte), and it just writes some zeros to the struct's padding bytes. On big endian systems, like s390x, it would write zero to I followed the instructions on https://docs.gitlab.com/omnibus/development/s390x.html to debug s390x using Docker and QEMU. I had to slightly modify their commands: in particular, I had to specify
|
oops, my bad thank you for all the details 🙏 |
Fix data races that would only be visible when using C extensions.
This is a follow-up on #119368.
I'm intentionally not testing:
_Py_T_NONE
(deprecated)_Py_T_OBJECT
(deprecated)Py_T_STRING
(immutable)Py_T_STRING_INPLACE
(immutable)Py_T_CHAR
For some reason
Py_T_CHAR
is untested also intest_capi.test_structmembers
.In fact, it's not even in the supporting C types, which I'm using for the TSAN tests as well: old api, new api.
I'm wondering if there's a specific reason for this, or if it should be in the test suite instead.
I'm guessing that the TSAN suite should cover the thread-safety of
Py_T_CHAR
regardless?Or should we dismiss it for TSAN tests as well?
I've added a new member to the
T_CHAR
member to the_testcapi
module, and the rest of the tests don't seem to break.I can revert this change if needed.