Bug 626756
Summary: | test_dbm fails on ppc64 & s390x | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Petr Šplíchal <psplicha> |
Component: | python | Assignee: | Dave Malcolm <dmalcolm> |
Status: | CLOSED ERRATA | QA Contact: | Petr Šplíchal <psplicha> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 6.0 | CC: | ohudlick |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | python-2.6.6-2.el6 | Doc Type: | Bug Fix |
Doc Text: |
Previously, the "in" operator for dbm mappings erroneously returned False for all keys on big-endian 64-bit builds of Python (ppc64 and s390x). This update fixes this issue.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2011-05-19 11:36:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 624821, 627266, 629274 | ||
Bug Blocks: |
Description
Petr Šplíchal
2010-08-24 10:37:53 UTC
All of the various headers in gdbm-devel-1.8.0-36.el6.ppc64 define datum as: typedef struct { char *dptr; int dsize; } datum; Note the use of "int" for dsize. This fragment of code in python's Modules/dbmmodule.c:dbm_contains: if (PyString_AsStringAndSize(v, (char **)&key.dptr, (Py_ssize_t *)&key.dsize)) { return -1; } assumes that sizeof(datum.dsize) == sizeof(Py_ssize_t) which is not correct on these architectures; on ppc64: (gdb) p sizeof(key.dsize) $25 = 4 (gdb) p sizeof(Py_ssize_t) $26 = 8 On ppc64, when PyString_AsStringAndSize writes the 0x00000000000000001 value for the ob_size of "a" to &key.dsize, I believe the 0x00000000 part is written to &key.size, and the 0x00000001 part is written to the 4 bytes following it, due to the incorrect cast from (int*) to (Py_ssize_t*) Thankfully (gdb) p sizeof(key) $28 = 16 so I believe it writes this value to padding within the "datum key", rather than corrupting the stack. The dbm_fetch() is thus invoked with a 0 dsize, and doesn't find the key, hence the test fails. The various other uses with that source file appear correct: (i) there are various PyArg_Parse* calls using s#, with int, which is correct, given the absence of the PY_SSIZE_T_CLEAN macro. (ii) there are various calls of PyString_FromStringAndSize(, datum.dsize), which I believe is correct: I believe the compiler will coerce this int to the wider Py_ssize_t type. Filed upstream as http://bugs.python.org/issue9687, with a patch Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, the "in" operator for dbm mappings erroneously returned False for all keys on big-endian 64-bit builds of Python (ppc64 and s390x). This update fixes this issue. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0554.html An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0554.html |