Compiling dev-lang/python:2.7 under the hardened/linux/amd64/no-multilib profile with a gcc with enabled pie and ssp results in a segfault in quodlibet: tamiko@northernraven ~ % quodlibet ** Message: pygobject_register_sinkfunc is deprecated (GstObject) W: Could not import python-gpod, iPod support disabled. zsh: segmentation fault quodlibet The backtrace indicates that the segfault occurs during a ffi call via the ctypes interface: #0 udev_enumerate_get_udev (udev_enumerate=0x56dcbd70) at libudev/libudev-numerate.c:145 #1 0x00007fffd6d7c5d2 in udev_enumerate_add_match_property udev_enumerate=0x56dcbd70, property=<optimized out>, value=<optimized out>) at libudev/libudev-enumerate.c:437 #2 0x00007ffff1ab9674 in ffi_call_unix64 () at ../src/x86/unix64.S:75 #3 0x00007ffff1ab8f74 in ffi_call (cif=0x7fffffffcdc0, fn=0x7fffd6d7c580 <udev_enumerate_add_match_property>, rvalue=<optimized out>, avalue=<optimized out>) at ../src/x86/ffi64.c:486 #4 0x00007fffd486649f in _call_function_pointer (argcount=3, resmem=0x7fffffffccd0, restype=<optimized out>, atypes=<optimized out>, avalues=0x7fffffffcca0, pProc=0x7fffd6d7c580 <udev_enumerate_add_match_property>, flags=4353) at /var/tmp/portage/dev-lang/python-2.7.2-r3/work/Python-2.7.2/Modules/_ctypes/callproc.c:827 #5 _ctypes_callproc (pProc=0x7fffd6d7c580 <udev_enumerate_add_match_property>, argtuple=<optimized out>, flags=4353, argtypes=<optimized out>, restype=0x555555f06bc0, checker=0x0) at /var/tmp/portage/dev-lang/python-2.7.2-r3/work/Python-2.7.2/Modules/_ctypes/callproc.c:1174 #6 0x00007fffd485f23c in PyCFuncPtr_call (self=<optimized out>, inargs <optimized out>, kwds=0x0) Temporarily disabling the use of the class UdevWrapper(object): in /usr/lib64/python2.7/site-packages/quodlibet/devices/__init__.py mitigates the segfault. Rebuilding dev-lang/python-2.7.2-r3 with the x86_64-pc-linux-gnu-4.5.3-hardenednopiessp gcc-specs-file results also in no segfault. Reproducible: Always Steps to Reproduce: 1. Recompile gcc/binutils under a hardened profile 2. Recompile dev-lang/python with a gcc spec with enabled pie and ssp Actual Results: quodlibet segfaults during a ffi call to libudev.so.0.11.5 using the ctypes interface from python. Expected Results: No segfault should occur.
Created attachment 304835 [details] gdb backtrace for quodlibet
Created attachment 304837 [details] strace for quodlibet
Created attachment 304839 [details] strace for quodlibet
Created attachment 304841 [details] emerge --info
*** This bug has been marked as a duplicate of bug 329499 ***
(In reply to comment #5) > > *** This bug has been marked as a duplicate of bug 329499 *** Are you sure, that this is a duplicate of bug 329499 ? bug 329499 explicitly tells about the ctypes interface failing due to using a pax enabled kernel via hardened-sources. But, I'm running the gentoo-sources patchset without pax. I merely compiled the whole userland under the hardened profile to enable pic and ssp. Furthermore the ctypes regression test suite does run fine.
(In reply to comment #6) > (In reply to comment #5) > > > > *** This bug has been marked as a duplicate of bug 329499 *** > > Are you sure, that this is a duplicate of bug 329499 ? > > bug 329499 explicitly tells about the ctypes interface failing due to using > a pax enabled kernel via hardened-sources. > > But, I'm running the gentoo-sources patchset without pax. > > I merely compiled the whole userland under the hardened profile to enable > pic and ssp. > > Furthermore the ctypes regression test suite does run fine. Opps sorry, Can you check if is pie or ssp that break it?
Building dev-lang/python:2.7 with [1] x86_64-pc-linux-gnu-4.5.3 --> segfault [2] x86_64-pc-linux-gnu-4.5.3-hardenednopie --> o.k. [3] x86_64-pc-linux-gnu-4.5.3-hardenednopiessp --> o.k. [4] x86_64-pc-linux-gnu-4.5.3-hardenednossp --> segfault [5] x86_64-pc-linux-gnu-4.5.3-vanilla --> o.k. So it seems to be pie.
Time to retry with quodlibet-3.0.2 which was largely rewritten (pygobject-3.x, introspection, and so forth) Please
> Time to retry with quodlibet-3.0.2 which was largely rewritten Thanks a lot for the message. I can no longer reproduce with media-sound/quodlibet-3.0.2 and with dev-lang/python-2.7.5-r3 compiled with sys-devel/gcc-4.7.3-r1 with hardened profile (pie + ssp).
I believe the original problem might still be there in python, it's just that new quodlibet no longer uses the code that triggers it. But since there isn't a patch, nor the issue was ever debugged to a level we could get proper upstream report for, I believe this is enough to close the *Gentoo* bug.