Issue 9960: test_structmembers fails on s390x (bigendian 64-bit): int/Py_ssize_t issue (original) (raw)
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 9.99999, 10.1010101010, "hi") ValueError: string too long
_testcapimodule.c: test_structmembers_new's fmt has: "s#" and these args: &s, &string_len
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 string_len $2 = 8589934592
(gdb) p /x string_len $3 = 0x200000000
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.
My reading of Python/getargs.c is that this macro does affect "u#" in a > manner analogous to "s#"; does this documentation need clarifying?
Probably. Same for "es#", "et#" and "t#" perhaps?