Bug 1127310
Summary: | ERROR: testBinaryPayload (test.test_xattr.xattrTest) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mark Hamzy <hamzy> | ||||
Component: | pyxattr | Assignee: | Marcin Zajaczkowski <mszpak> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | urgent | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 21 | CC: | bkabrda, dan, dmalcolm, ivazqueznet, jonathansteffan, mstuchli, mszpak, rkuska, tomspur, tradej | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | ppc64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2014-08-07 15:32:01 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Mark Hamzy
2014-08-06 15:38:52 UTC
At a glance, I would guess that this is a type mismatch between format code "Oetet#|ii" in the call to PyArg_ParseTupleAndKeywords vs the underlying types of the variables being written to. See https://docs.python.org/2/c-api/arg.html In particular, "et#" is documented as taking: [const char *encoding, char **buffer, int *buffer_length] which would seems to suggest that &bufsize ought to be an "int *". However, "s#" has: >Starting with Python 2.5 the type of the length argument can be controlled by >defining the macro PY_SSIZE_T_CLEAN before including Python.h. If the macro is >defined, length is a Py_ssize_t rather than an int. and IIRC that *does* in fact affect "et#" and the other hash-suffixed codes i.e. PyArg_ParseTupleAndKeywords was expecting bufsize to be a Py_ssize_t, not an int. (see Python/getargs.c, and the "FETCH_SIZE" macro there; if PyArg_ParseTupleAndKeywords has been expanded to a call to PyArg_ParseTupleAndKeywords_SizeT that's what's going on). I did see: (gdb) s _PyArg_ParseTupleAndKeywords_SizeT (args=('/builddir/build/BUILD/pyxattr-0.5.3/xattr-wKlyFZ.test', u'user.test', 'abc\x00def'), keywords=0x0, format=0x3fffaff33fd8 "Oetet#|iis", kwlist=0x3fffaff52ef8 <kwlist>) at /usr/src/debug/Python-2.7.7/Python/getargs.c:1454 1454 if ((args == NULL || !PyTuple_Check(args)) || And the top of the file contains: #define PY_SSIZE_T_CLEAN #include <Python.h> (In reply to Mark Hamzy from comment #3) > And the top of the file contains: > > #define PY_SSIZE_T_CLEAN > #include <Python.h> Thanks. The fix then, probably, is to change: int bufsize; to: Py_ssize_t bufsize; Created attachment 924571 [details] proposed patch [root@bluebill ~]# ppc-koji build --scratch f21 /home/mock/SHADOWBUILD-f21-build-repo_390420/root/builddir/build/SRPMS/pyxattr-0.5.3-1.fc21.src.rpm Created task: 1978031 Task info: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1978031 ... 1978031 build (f21, pyxattr-0.5.3-1.fc21.src.rpm) completed successfully [root@bluebill ~]# koji build --scratch f21 /home/mock/SHADOWBUILD-f21-build-repo_390420/root/builddir/build/SRPMS/pyxattr-0.5.3-1.fc21.src.rpm Created task: 7250277 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=7250277 ... 7250277 build (f21, pyxattr-0.5.3-1.fc21.src.rpm) completed successfully Thanks guys for the proposed patch. I'm not a Python developer and I can't say how much it could impact builds for other architectures and the library itself. I sent a link to that issue to the pyxattr's author to ask for comments. I would be nice to have it fixed upstream anyway. Marcin, the other architectures just have enough luck they are not affected by the type mismatch :-) Please include the patch in the package ASAP, it blocks f21 (and rawhide later) builds on Fedora/ppc. I applied the patch. Let me know if you need anything more with this package. thanks, please do builds in both f21 and rawhide, the secondary arches will then inherit them automagically I already did just after pushing the changes: http://koji.fedoraproject.org/koji/buildinfo?buildID=551358 http://koji.fedoraproject.org/koji/buildinfo?buildID=551359 But maybe you are talking about some other kind of builds? ah, thanks, then everything is done, I haven't checked koji because I saw the MODIFIED state which usually means changes committed, but not built yet. You can close the bug. Ok. |