If coreutils ebuild is compiled with xattr flag cp command will crash every time it is called from an openoffice ebuild. Reproducible: Always Steps to Reproduce: 1.add user_xattr for every fs in /etc/fstab 2.USE=xattr emerge -1 coreutils 3.emerge openoffice-4.3.0 Portage 2.1.5_rc2 (default-linux/amd64/2007.0, gcc-4.2.3, glibc-2.7-r2, 2.6.25-rc8-git7 x86_64) ================================================================= System uname: 2.6.25-rc8-git7 x86_64 AMD Phenom(tm) 9500 Quad-Core Processor Timestamp of tree: Fri, 11 Apr 2008 11:45:03 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.5 dev-lang/python: 2.5.1-r5 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.62 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.24 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O3 -pipe" CHOST="x86_64-pc-linux-gnu" LANG="fr_FR.UTF-8" LC_ALL="fr_FR.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="fr" MAKEOPTS="-j8" PKGDIR="/usr/portage/packages"
post the actual build logs as well as your /etc/fstab as attachments
Created attachment 149545 [details] openoffice 2.4.0 ebuild output USE flags are: cups dbus gnome gstreamer gtk pam webdav xulrunner LINGUAS="fr"
Created attachment 149547 [details] coreutils ebuild output (with xattr)
Created attachment 149549 [details] fstab with user_xattr
(In reply to comment #1) > post the actual build logs as well as your /etc/fstab as attachments > Thx for taking your time to help me to figure out what the problem could be. I need xattr because of beagle that use it heavily. the kernel was compiled with the following flags, grep XATTR .config CONFIG_EXT2_FS_XATTR=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT4DEV_FS_XATTR=y CONFIG_REISERFS_FS_XATTR=y CONFIG_CIFS_XATTR=y The output line that breaks openoffice ebuild is the one that contains GNUCP I don't have a config.log anymore but GNUCP was set to cp. The line in fstab: /dev/vg/tmp /var/tmp ext3 noatime,acl,data=writeback 0 2 was set with the user_xattr during the tests. I will try with the new coreutils -r2 again an see if there is any improvements.
Same problem with coreutils -r2 when xattr flag is set.
Funny, compiling coreutils-6.10-r2 without xattr again make it abort when it calles cp too (compiled with coreutils-6.10-r2 with xattr flag) :) mv -f alloca.h-t alloca.h mv fcntl.h-t fcntl.h mkdir -p selinux mv configmake.h-t configmake.h cp ./se-selinux.in.h selinux/selinux.h-t make[1]: *** [selinux/selinux.h] Segmentation fault make[1]: *** Waiting for unfinished jobs.... mv math.h-t math.h mv inttypes.h-t inttypes.h make[1]: Leaving directory `/var/tmp/portage/sys-apps/coreutils-6.10-r2/work/coreutils-6.10/lib' make: *** [all-recursive] Erreur 1 * * ERROR: sys-apps/coreutils-6.10-r2 failed.
IMHO, the bug cannot be hidden in the libraries called by cp. Indeed, after moving /bin/cp (version 6-10-r2+xattr) to /bin/cp.old, I was able to copy cp (version 6-10-r1 w/o xattr saved with quickpkg earlier) into /bin again. I didn't change the libraries, so cp and cp.old were using the same.
(In reply to comment #8) the same _libraries_ of course :)
so you're saying if you emerge with USE="acl -xattr", cp does not crash ?
(In reply to comment #10) > so you're saying if you emerge with USE="acl -xattr", cp does not crash ? > yes.
hrm, i cant reproduce this ... dd if=/dev/zero of=loop count=1024 mke2fs loop mkdir mnt mount -o loop,acl,user_xattr loop mnt cd mnt touch a cp a b i have xattrs turned on in my kernel for ext2/ext3 ... could you try this test and see if things fail for you ?
(In reply to comment #12) > hrm, i cant reproduce this ... > > dd if=/dev/zero of=loop count=1024 > mke2fs loop > mkdir mnt > mount -o loop,acl,user_xattr loop mnt > cd mnt > touch a > cp a b > It works but the command "ebuild openoffice-2.4.0.ebuild install" broke again. I made the same test without xattr_user for /var/tmp(/portage) tree and as surprisingly it is I was unable to emerge openoffice too. I even tried the test in the /var/tmp/portage/app-office/openoffice-2.4.0/work/ooo/build/OOH680_m12/ directory and it still works. I changed slightly the test and added a journal (etx3) to a bigger loop file. No go, it works. I have downgraded the attr package and nothing doing the test works but not openoffice installation as usual. That's sounded crazy enough to me and made me hesitate to report that stupid bug... Have you tried to emerge openoffice 2.4.0 ? Has it worked ? Also, most of the gtk python tools I run as user will return an annoying segmentation fault when I'm not exporting MALLOC_CHECK_=2 or 1. Perhaps that bug has something to do whith how glibc 2.7 malloc is "managed" ? Actually, I don't overclock my system and the Phenom patch is activated in the bios. In case that could help, # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 38912 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 38912 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Thanks for your fast reply.
(In reply to comment #12) > hrm, i cant reproduce this ... with the line "export MALLOC_CHECK_=2" in /etc/env.d/01glibc, the issue has gone. I'm now sure it is related to the glibc 2.7 version and certainly is correlate with the kernel release too. Besides, it has corrected the python program crash. I suppose you didn't test it with the last glibc 2.7 release if you cannot reproduce it ?
my systems are all running latest versions of the toolchain if other things are crashing (like python) and they go away when setting an internal glibc variable, that suggests a lower layer is corrupting things ...
Created attachment 150367 [details, diff] coreutils-xattr.patch you can try this patch against coreutils-6.11 (it replaces the existing xattr patch in the patch tarball) ... but i'm not terribly confident that it'll fix your ails ...
(In reply to comment #15) > my systems are all running latest versions of the toolchain > > if other things are crashing (like python) and they go away when setting an > internal glibc variable, that suggests a lower layer is corrupting things ... > I will try to emerge all the system again. Could you suggest me any lower layers that interact with glibc I should take care in particularly ?
Comment on attachment 150367 [details, diff] coreutils-xattr.patch actually, ignore this patch ... it requires updates to the attr package which we dont have
(In reply to comment #16) > Created an attachment (id=150367) [edit] > coreutils-xattr.patch > > you can try this patch against coreutils-6.11 (it replaces the existing xattr > patch in the patch tarball) ... but i'm not terribly confident that it'll fix > your ails ... > I will give a try. For now, I just upgraded to the last stable 2.6.25 kernel, linux-header 2.6.25 header, emerge -uDvab --newuse the world and also emerged glibc again. I made some new tests with coreutils 6.11 and the default 004_all_coreutils-acl-xattr.patch. I was able to show the issue with binutils and coreutils. The USE flags activated for the tests are: [ebuild R ] sys-devel/binutils-2.18-r1 USE="nls -multislot -multitarget -test -vanilla" 0 kB [ebuild R ] sys-apps/coreutils-6.11 USE="acl nls (-selinux) -static -vanilla -xattr" 0 kB Setting LDFLAGS="-Wl,-O1 -Wl,--as-needed" or LDFLAGS="-Wl,-z,now" doesn't change anything. MALLOC_CHECK_=2 is set in /etc/profile.env 1) With xattr USE flag desactivated binutils can always be emerged 2) with xattr USE flag activated binutils emerge aborts with a segmentation fault at the cp line, make[4]: entrant dans le répertoire « /var/tmp/portage/sys-devel/binutils-2.18-r1/work/build/bfd » rm -f bfd-tmp.h cp bfd-in3.h bfd-tmp.h make[4]: *** [stmp-bfd-h] Erreur de segmentation make[4]: *** Attente des tâches non terminées.... besides, coreutils 2.11 still fails to reemerge. The bug .. or the misconfiguration is quite severe and it affects now 3 of my machines. MALLOC_CHECK_ can be moved aside. It doesn't change anything and is just useful with python "binaries".
(In reply to comment #18) > (From update of attachment 150367 [details, diff] [edit]) > actually, ignore this patch ... it requires updates to the attr package which > we dont have > Let me know as soon as it is available. For now I will do an emerge -e system again. Thanks for taking your time on it.
The bug is still here in sys-apps/coreutils-6.12-r1 I was unable to build glib package when xattr was activated. cp does a nice segmentation fault. /bin/sh: line 2: 30436 Erreur de segmentation cp xgen-gmc gmarshal.c and even when reemerging... coreutils too. cp ./se-selinux.in.h selinux/selinux.h-t mv math.h-t math.h make[2]: *** [selinux/selinux.h] Segmentation fault I'm using ext3 filesystems
Created attachment 166274 [details] emerge --info
In case someone hits the bug, just do a busybox mv /bin/cp /bin/cp.BUG ln -s /bin/busybox /bin/cp and remerge coreutils w/ the -xattr flag again.
*** Bug 250882 has been marked as a duplicate of this bug. ***
*** Bug 259242 has been marked as a duplicate of this bug. ***
*** Bug 236866 has been marked as a duplicate of this bug. ***
should be fixed with coreutils-7.1
*** Bug 343075 has been marked as a duplicate of this bug. ***
