layman segfaults (on amd64 and x86 hardened systems with PAX) with segfault at c ip ... sp ... error 6 in libffi.so.6.0.1 if dev-python/ndg-httpsclient (with only PYTHON_TARGETS="python3_4") is installed. Note that the latter package is pulled in by the new version dev-python/requests-2.8.1 which has just been marked stable on amd64 and x86. (However, the problem occurs also with requests 2.6.0 if only ndg-httpsclient is installed) The problem disappears when switching PAX to softmode (/proc/sys/kernel/pax/softmode), but no paxmarking of libffi.so.6.0.1 avoided the segfault. Upgrading to libffi-3.2.1 does not help, either. Renaming the file /usr/lib64/python3.4/site-packages/cryptography/hazmat/bindings/_openssl.cpython-34.so from dev-python/cryptography-1.0.2 helps, but no paxmarking of that file avoids the segfault. Upgrading to cryptography-1.1 does not change anything. Perhaps there is a relation with bug 457194, especially with comment #30 because an strace ends with open("/proc/self/status", O_RDONLY) = 5 fstat(5, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x36040997000 read(5, "Name:\tlayman\nState:\tR (running)\n"..., 1024) = 848 close(5) = 0 munmap(0x36040997000, 4096) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EPERM (Operation not permitted) --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xc} --
check that you have emutramp on in the kernel and selected python have pax mark E set.
Thanks a lot! Setting EMUTRAMP in the kernel solved the problem. So it seems that there was nothing wrong except that now it is the first time that EMUTRAMP is really needed for my gentoo system. Sorry for the noise.
