[issue9688] object.__basicsize__ is erroneously 0 on big-endian 64-bit machines (int vs Py_ssize_t)
Dave Malcolm
report at bugs.python.org
Thu Aug 26 00:48:52 CEST 2010
New submission from Dave Malcolm <dmalcolm at redhat.com>:
On 64-bit bigendian machines (ppc64 and s390x), I'm seeing:
>>> print object.__basicsize__
0
(Discovered via a segfault in Jinja2 tries to use ctypes to manipulate ob_refcnt of variables, and gets the wrong location, corrupting the objects instead; see https://bugzilla.redhat.com/show_bug.cgi?id=627347 )
struct _typeobject declares tp_basicsize and tp_itemsize as Py_ssize_t:
{
...
Py_ssize_t tp_basicsize, tp_itemsize; /* For allocation */
...
}
but type_members defines them as T_INT:
{"__basicsize__", T_INT, offsetof(PyTypeObject,tp_basicsize),READONLY},
{"__itemsize__", T_INT, offsetof(PyTypeObject, tp_itemsize), READONLY},
Hence when accessing "object.__basicsize__", PyMember_GetOne reads it as a
T_INT, which gets it as 0 (incorrect). Accessing it as Py_ssize_t reads it as
16 (correct)
(gdb) p *(Py_ssize_t*)addr
$9 = 16
(gdb) p *(int*)addr
$10 = 0
I'm attaching a patch which changes them to use T_PYSSIZE_T and adds a selftest.
----------
keywords: +patch
stage: -> patch review
title: object.__basicsize__ is erroneously0 -> object.__basicsize__ is erroneously 0 on big-endian 64-bit machines (int vs Py_ssize_t)
type: -> behavior
versions: +Python 2.7
Added file: http://bugs.python.org/file18646/fix-typeobject-T_INT-usage.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9688>
_______________________________________
More information about the Python-bugs-list
mailing list