Author dmalcolm
Recipients dmalcolm
Date 2010-09-27.15:11:31
SpamBayes Score 7.87287e-09
Marked as misclassified No
Message-id <>
test test_structmembers crashed -- <type 'exceptions.ValueError'>:
string too long
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7/Lib/test/", line 863, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/builddir/build/BUILD/Python-2.7/Lib/test/", line 12, in <module>
    9.99999, 10.1010101010, "hi")
ValueError: string too long

_testcapimodule.c: test_structmembers_new's fmt has:
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. 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?
Date User Action Args
2010-09-27 15:11:36dmalcolmsetrecipients: + dmalcolm
2010-09-27 15:11:36dmalcolmsetmessageid: <>
2010-09-27 15:11:33dmalcolmlinkissue9960 messages
2010-09-27 15:11:32dmalcolmcreate