When I tried to copy some files from ~/code to a USB key, cp segfaulted. I recompiled coreutils and glibc with full debugging and the backtrace says that strlen() segfaulted when called from vprintf() when glibc tried to set attributes on the destination file. The program that initiated this chain was cp. My home dir is JFS and the USB key is VFAT. Reproducible: Always Steps to Reproduce: 1. Mount a vfat-formatted USB key 2. Copy a file from an attribute-supporting fs (ext2/3, jfs, etc) to one which doesn't support attributes (vfat, ntfs, etc.) Actual Results: segfault Expected Results: copied all the files This is the result of $gdb /bin/cp &>/dev/stdout | tee cplog ; cat cplog : GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu"... (gdb) (gdb) run code/*.c /mnt/usb0/code/ Starting program: /bin/cp code/*.c /mnt/usb0/code/ Program received signal SIGSEGV, Segmentation fault. strlen () at ../sysdeps/x86_64/strlen.S:37 37 ../sysdeps/x86_64/strlen.S: No such file or directory. in ../sysdeps/x86_64/strlen.S Current language: auto; currently asm (gdb) bt #0 strlen () at ../sysdeps/x86_64/strlen.S:37 #1 0x00007f09e9d0eb0e in vfprintf () from /lib/libc.so.6 #2 0x00007f09e9d36fba in vsnprintf () from /lib/libc.so.6 #3 0x00000000004045e6 in copy_attr_error (ctx=<value optimized out>, fmt=0x7f09ea03b6fc "setting attributes for %s") at copy.c:154 #4 0x00007f09ea03b04e in attr_copy_file () from /lib/libattr.so.1 #5 0x0000000000404c00 in copy_extended_attributes (src_path=0x7ffff266514a "code/bmpdiff.c", dst_path=0x1c283c0 "/mnt/usb0/code/bmpdiff.c", x=0x7ffff2663310) at copy.c:228 #6 0x000000000040764e in copy_internal (src_name=0x7ffff266514a "code/bmpdiff.c", dst_name=0x1c283c0 "/mnt/usb0/code/bmpdiff.c", new_dst=false, device=0, ancestors=0x0, x=0x7ffff2663310, command_line_arg=true, copy_into_self=0x7ffff266321e, rename_succeeded=0x0) at copy.c:793 #7 0x0000000000407a61 in copy (src_name=0x6 <Address 0x6 out of bounds>, dst_name=0x7f09ea03b713 "%s", nonexistent_dst=216, options=<value optimized out>, copy_into_self=<value optimized out>, rename_succeeded=<value optimized out>) at copy.c:2211 #8 0x000000000040398a in do_copy (n_files=6, file=0x7ffff2663470, target_directory=0x7ffff26651a3 "/mnt/usb0/code/", no_target_directory=<value optimized out>, x=0x7ffff2663310) at cp.c:702 #9 0x000000000040433d in main (argc=7, argv=0x7ffff2663468) at cp.c:1133 (gdb) quit The program is running. Exit anyway? (y or n) Relevant info from emerge --info: Portage 2.1.6.1 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.9_p20081201-r0, 2.6.27-gentoo-r5 x86_64) ================================================================= System uname: Linux-2.6.27-gentoo-r5-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T9400_@_2.53GHz-with-glibc2.2.5 Timestamp of tree: Sat, 13 Dec 2008 06:01:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p48 dev-java/java-config: 1.3.7-r1, 2.1.6-r1 dev-lang/python: 2.4.4-r13, 2.5.2-r8 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.2 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.3.0-r1 sys-apps/sandbox: 1.3.0 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=native -g -ggdb" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/4.1/env /usr/kde/4.1/share/config /usr/kde/4.1/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -march=native -g -ggdb" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages nostrip parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" LINGUAS="en en_US" MAKEOPTS="-j4" USE flags for glibc: debug gd glibc-omitfp multilib nls USE flags for coreutils: acl nls xattr Note: this bug prevents files from being copied to and from Windows (ntfs) or vfat paritions. This bug may cause Wine to crash and breaks the usefulness of ntfs-3g. The only solution I can find is to hard-mask sys-libs/glibc-2.9_p20081201 until a fix is found. This should also be posted on the glibc bugzilla. vfat-{vfat,ntfs}, and vfat-{ext2,jfs} copies work. What is happening is that, when cp tries to print an error saying that attributes cannot be set in destination, an overflow in strlen is triggered.
Looking at the sources, a PF is thrown by the CPU when evaluating: cmpb $0x0,(%rax) Previously, %rax is set to %edi. Debugging in gdb, %rax is equal to 6. This is a sign of a null pointer.
probably dupe of Bug 217290
But the dupe is only triggered in glibc 2.9. Interesting...
which doesnt really say too much when you're talking about random memory corruption
I have a very strong feeling that xattr and glibc-2.9 aren't getting along, which seems to be the root cause of the crash.
can you verify that building coreutils with USE=-xattr fixes things ?
USE=-xattr fixes the problem. Is there a reason why xattr is picky with regards to glibc version?
that's what happens with bad memory usage ... *** This bug has been marked as a duplicate of bug 217290 ***
