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
test_structmembers fails on s390x (bigendian 64-bit): int/Py_ssize_t issue #54169
Comments
test test_structmembers crashed -- <type 'exceptions.ValueError'>:
string too long
Traceback (most recent call last):
File "/builddir/build/BUILD/Python-2.7/Lib/test/regrtest.py", line 863, in runtest_inner
the_package = __import__(abstest, globals(), locals(), [])
File "/builddir/build/BUILD/Python-2.7/Lib/test/test_structmembers.py", line 12, in <module>
9.99999, 10.1010101010, "hi")
ValueError: string too long _testcapimodule.c: test_structmembers_new's fmt has: for grabbing this data:
const char *s = NULL;
Py_ssize_t string_len = 0; However, the module doesn't define PY_SSIZE_T_CLEAN, which leads to &string_len being treated as an (int*) rather than a (Py_ssize_t*) and thus written to with just the first 32-bits of the size, rather than the full size. The PyArgs_ call without PY_SSIZE_T_CLEAN writes the size of the string (2) through (int*)&string_len, writing 0x00000002 to the first 4 bytes, setting the 64-bit "string_len" value to 0x0000000200000000 i.e. 2^34, wildly too large for the iirc 5 byte buffer. Confirmed in gdb: (gdb) p /x string_len Am attaching a patch (against 2.7 maintenance branch) which defines PY_SSIZE_T_CLEAN; doing so requires updating another int to be a Py_ssize_t in that module, within test_u_code. http://docs.python.org/c-api/arg.html lists "u# (Unicode) [Py_UNICODE *, int]" and has no reference to the effect of PY_SSIZE_T_CLEAN on the "u#" format specifier. My reading of Python/getargs.c is that this macro does affect "u#" in a manner analogous to "s#"; does this documentation need clarifying? |
Is this 2.7-specific? Otherwise, it would be better to provide a patch for 3.2 first, and then svnmerge to other branches.
Probably. Same for "es#", "et#" and "t#" perhaps? |
FWIW, this regressed in 2.6.6 relative to 2.6.5, due to r79646 adding the T_STRING_INPLACE test code to the 2.6 branch. Note to self: https://bugzilla.redhat.com/show_bug.cgi?id=677392 |
The originally attached patch is no good for the the 2.* branch, as it appears that _testcapimodule.c will not become "ssize_t" safe in Python 2.*; see e.g.: Am attaching a revised patch that I'm applying downstream in Fedora's builds of 2.7.3 |
I believe that the change in the later patch has already been applied to the 2.7 branch. If I'm correct can we close this please. |
This was fixed in bpo-17928. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: