New submission from Dave Malcolm <dmalc...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue9688> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
