Created attachment 380382 [details] emerge --info I have posted this issue on the gentoo forums and was told to file a bug. Here is the original forum posting http://forums.gentoo.org/viewtopic-t-994638.html I can't seem to emerge setuptools, and some related packages, namely virtualenv, Also certain ruby packages fail as well, though I believe they are not related to the problem. I have tried the following (some of this is mentioned there, some not) emerge -uDN world emerge -uDN system (Was working but now fails due to setuptools aswell) emerge -uDNe python emerge -C setuptools (Bug 297017) emerge -C virtualenv emerge -C virtualenvwrapper emerge -C virtualenv-clone emerge -uDN setuptools emerge -1 dev-lang/python (Bug 314881) python-updater It appears reproducible i.e. emerge world/setuptools fail even after running emerge --sync a week after the first occurence. I have run the above commands both with PYTHON_TARGETS = "Python2_7 Python3_4" and PYTHON_USE = "2.7 3.4" set and unset in my /etc/portage/make.conf. I am running on a gentoo hardened installation if this is relevant and have also tried combinations of the above commands with FEATURES="-selinux" preceding the emerge command as in FEATURES="-selinux" emerge ... I have attache my emerge --info output and will attach the build and log info if the interface allows it. If you need any further information please let me know.
Created attachment 380384 [details] emerge pqv This is the emerge -pqv output
Created attachment 380386 [details] build.log This is the log generated by emerge that shows the compilation and subsequent failure of teh package
That's a segmentation fault in cp. Can you reproduce the issue? Can you get a gdb backtrace? dmesg output?
Created attachment 380920 [details] Dmesg for my system. The problem is repeatable. I have just tried to emerge -uDN world/system and it still fails at the same place, namely installing setuptools. This is my dmesg message. I have not run the machine since I posted last time.
Created attachment 380924 [details] Funny Emerge output fro setuptools I ran 'FEATURES='nostrip' emerge setuptools' again just to be sure. The one set of lines states : ... >>> Install setuptools-5.4.1 into /var/tmp/.../ category python * python3_4: running distutils-r1_run_phase python_install /usr/bin/python3.4 setup.py install --compile -O2 --root=/var/tmp/portage/dev-python/setuptools-5.4.1//_python3.4 --install-scripts=/usr/lib/python-exec/python3.4 python3.4 running install ... Is the // supposed to be there ? It occurs around about the middle of the middle line, in the file name.
I re-read the Bugzilla "How to" to see how to perform the backtrace. The thing is I do not know what to substitute for the BAD_CODE part. It seems the failure occurs when the command : [code] /usr/bin/python3.4 setup.py install --compile -O2 --root/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.4 --install-scripts=/usr/lib/python-exec/ [code] is called. Which means that there is no application to run to see when it fails other then python3.4 itself. I figure I'm missing something rudimentary here but I am not sure what you want me to run to generate the backtrace. That command however does execute fine if I'm under the working directory pointed at by the emerge command.
I'm pretty sure that has nothing to do with it. The segfault is coming from the cp command at line 295 of multibuild.eclass. Does the cp command actually work on your system? I assume it must or all sorts of stuff would be broken, but please check by copying some random files. Another thing that might be triggering it is the specific options we are passing to cp. --reflink=auto is relatively new, so that might be buggy. Maybe try commenting out lines 290 to 293 of /usr/portage/eclass/multibuild.eclass: if cp --reflink=auto --version &>/dev/null; then # enable reflinking if possible to make this faster cp_args+=( --reflink=auto ) fi
Created attachment 380946 [details] emerge --debug setuptools I tried commenting out the commands you suggested, the build failed. I additionally commented out the lines 215 - 218, which also use cp with the --reflink switch, the build failed. I then forced --reflink=always, as per "man cp", build failed but differently. I got an error message stating : cp : failed to clone from â to â : Inappropriate ioctl for device. I'm not sure it â, a circumflex, is meant to be there. It seemed an odd character in the string. I have posted the "emerge --debug setuptools" with --reflink=auto in lieu of a back trace, I'm still unsure how to produce that or if it's needed. I also tried setting the if statement to have --reflink=auto and the command in the if statement to have --reflink=always, the build failed. Vice versa was tried aswell, the build failed. This is probably not relevant but I saw on an old forum that cp may be fixed if one rebuilt coreutils with the command "USE="-xattr" emerge -1 sys-apps/coreutils". Which I tried, followed with emerge setuptools, the build failed. I rebuilt my coreutils with emerge -uDN1 sys-apps/coreutilss, just so that I don't change too many variables at one time.
I am running into a similar issue in a virtual machine (kvm-qemu) trying to install gdbus-codegen-2.40.0. The system console shows messages similar to: [ 3016.538517] cp[3912]: segfault at 0 ip 00006eca120cf2fa sp 00007261873b7278 error 4 in libc-2.19.so[6eca12044000+1b3000] Error from the ebuild: running install_egg_info Writing /var/tmp/portage/dev-util/gdbus-codegen-2.40.0/image//_python3.3/usr/lib64/python3.3/site-packages/gdbus_codegen-2.40.0-py3.3.egg-info /var/tmp/portage/dev-util/gdbus-codegen-2.40.0/temp/environment: line 2475: 10265 Segmentation fault cp "${cp_args[@]}" "${src}"/. "${dest}"/ I'm currently set with PYTHON_TARGETS="python2_7 python3_3" and have tried just building with just 2.7 or 3.3, but still segfaults.
Looking at your --debug log, this is the failing command: cp -a --reflink=auto /var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.4/. /var/tmp/portage/dev-python/setuptools-5.4.1/image// Could you try calling it manually after the failing build (so that directories will be created already)? Please try manipulating it a bit -- removing some of the options, double slashes, '.' after '/'.
Have the same bug. It fails only on python3.3 installation, done perfectly on python2.7. Here is the build log http://xvilka.me/setuptools-build.log And here is the strace output http://xvilka.me/cp_strace.log openat(AT_FDCWD, "/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.3/.", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC) getdents64(3, /* 3 entries */, 32768) = 72 getdents64(3, /* 0 entries */, 32768) = 0 close(3) = 0 lstat64("/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.3/./usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var/tmp/portage/dev-python/setuptools-5.4.1/image/./usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lgetxattr("/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.3/./usr", "security.selinux", "staff_u:object_r:portage_tmp_t", 255) = 31 openat(AT_FDCWD, "/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.3/./usr", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 getdents64(3, /* 4 entries */, 32768) = 96 getdents64(3, /* 0 entries */, 32768) = 0 close(3) = 0 lstat64("/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.3/./usr/bin", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var/tmp/portage/dev-python/setuptools-5.4.1/image/./usr/bin", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lgetxattr("/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.3/./usr/bin", "security.selinux", "staff_u:object_r:portage_tmp_t", 255) = 31 openat(AT_FDCWD, "/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.3/./usr/bin", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 getdents64(3, /* 3 entries */, 32768) = 80 getdents64(3, /* 0 entries */, 32768) = 0 close(3) = 0 lstat64("/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.3/./usr/bin/easy_install", {st_mode=S_IFLNK|0777, st_size=31, ...}) = 0 lstat64("/var/tmp/portage/dev-python/setuptools-5.4.1/image/./usr/bin/easy_install", {st_mode=S_IFLNK|0777, st_size=31, ...}) = 0 stat64("/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.3/./usr/bin", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat64("/var/tmp/portage/dev-python/setuptools-5.4.1/image/./usr/bin", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 unlink("/var/tmp/portage/dev-python/setuptools-5.4.1/image/./usr/bin/easy_install") = 0 lgetxattr("/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.3/./usr/bin/easy_install", "security.selinux", "staff_u:object_r:portage_tmp_t", 255) = 31 readlink("/var/tmp/portage/dev-python/setuptools-5.4.1/image//_python3.3/./usr/bin/easy_install", "../lib/python-exec/python-exec2", 32) = 31 symlink("../lib/python-exec/python-exec2", "/var/tmp/portage/dev-python/setuptools-5.4.1/image/./usr/bin/easy_install") = 0 open("/proc/self/task/6911/attr/fscreate", O_RDWR|O_LARGEFILE|O_CLOEXEC) = 3 write(3, NULL, 0) = 0 close(3) = 0 lchown32("/var/tmp/portage/dev-python/setuptools-5.4.1/image/./usr/bin/easy_install", 0, 0) = 0 utimensat(AT_FDCWD, "/var/tmp/portage/dev-python/setuptools-5.4.1/image/./usr/bin/easy_install", {{1405761293, 905702732}, {1405761293, 905702732}}, AT_SYMLINK_NOFOLLOW) = 0 open("/proc/self/task/6911/attr/fscreate", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 read(3, "", 4095) = 0 close(3) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x8} --- +++ killed by SIGSEGV +++
Sorry, I can't run gdb on my installation, due to some incompatibility of security policy and ptracing (PaX configs), and can't reboot machine now due to broken update, thx to this bug. But I have tested similar case on another machine - python2.7 and python3.3 and installing setuptools-5.4.1 - all works perfectly (it is amd64 machine), while I'm experiencing this bug on the 32bit machine.
> But I have tested similar case on another machine - python2.7 and python3.3 > and installing setuptools-5.4.1 - all works perfectly (it is amd64 machine), > while I'm experiencing this bug on the 32bit machine. Forgot to mention - bug is reproducible on hardened (PaX + selinux) machine, and not reproducible on the generic Gentoo installation. I strongly believe it related somehow to SELinux.
Re-assigning since the segfault is happening within cp, hopefully the maintainers will be more helpful. CC-ing selinux@ as suggested by Anton.
> Forgot to mention - bug is reproducible on hardened (PaX + selinux) machine, > and not reproducible on the generic Gentoo installation. I strongly believe > it related somehow to SELinux. Ditto. This is happening to me in a hardened environment.
*** This bug has been marked as a duplicate of bug 508684 ***
