Valgrind 3.7.0 emerges but fails to run. Downgrading to 3.6.1, makes the problem go away. Output for valgrind ls with version 3.7.0 valgrind ls ==15757== Memcheck, a memory error detector ==15757== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==15757== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==15757== Command: ls ==15757== valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: strlen valgrind: in an object with soname matching: ld-linux.so.2 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux.so.2 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind: On Debian, Ubuntu: libc6-dbg valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Cannot continue -- exiting now. Sorry. Reproducible: Always
emerge --info Portage 2.1.10.34 (default/linux/x86/10.0/developer, gcc-4.5.3, glibc-2.13-r4, 3.1.0-gentoo i686) ================================================================= System uname: Linux-3.1.0-gentoo-i686-Intel-R-_Pentium-R-_4_CPU_3.20GHz-with-gentoo-2.1 Timestamp of tree: Sat, 12 Nov 2011 12:30:01 +0000 app-shells/bash: 4.2_p10 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.6.7-r2, 2.7.2-r3, 3.2.2 dev-util/cmake: 2.8.6-r3 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1 sys-apps/openrc: 0.9.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1-r1 sys-devel/binutils: 2.21.1-r1 sys-devel/gcc: 3.4.6-r2, 4.2.4-r1, 4.3.6-r1, 4.4.6-r1, 4.5.3-r1, 4.6.2 sys-devel/gcc-config: 1.5-r2 sys-devel/libtool: 2.4-r4 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 2.6.39 (virtual/os-headers) sys-libs/glibc: 2.13-r4 Repositories: gentoo kde-sunset sunrise sage-on-gentoo local-repo mingw32-repo ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.0/conf /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs collision-protect distlocks ebuild-locks fixlafiles multilib-strict news parallel-fetch protect-owned sandbox sfperms sign splitdebug strict test-fail-continue unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox" FFLAGS="" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ ftp://ftp.gtlib.gatech.edu/pub/gentoo http://www.gtlib.gatech.edu/pub/gentoo ftp://mirror.iawnet.sandia.gov/pub/gentoo/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.chem.wisc.edu/gentoo/ " LANG="en_US.UTF-8" LDFLAGS="-Wl,--as-needed" LINGUAS="en en_US fr" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--exclude ChangeLog --delete-excluded" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/kde-sunset /var/lib/layman/sunrise /var/lib/layman/sage-on-gentoo /usr/local/portage /usr/i686-mingw32/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa apache2 berkdb bluetooth bzip2 cairo cdda cdr cleartype cli consolekit corefonts cpdflib cracklib crypt cups cxx dbus doc dri dts dv dvd dvdr emboss encode exif fam firefox flac fortran gcj gd-external gdbm gdu gif gnomedb gpm gtk iconv ieee1394 ipv6 java jpeg kde kdehiddenvisibility lcms ldap libnotify lm_sensors mad maildir mbox mmx mng modules mp3 mp4 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pango pcre pdf php png policykit ppds pppd private-headers qt3support qt4 readline scanner sdl semantic-desktop session snmp spell sqlite sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype type1 type3 udev unicode usb vorbis wicd x264 x86 xcb xml xmlrpc xorg xulrunner xv xvid zlib" ALSA_CARDS="intel8x0 usb-audio" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="canon" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev keyboard mouse virtualbox" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US fr" NETBEANS_MODULES="apisupport harness ide java nb gsf php websvccommon webcommon" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" SANE_BACKENDS="umax" USERLAND="GNU" VIDEO_CARDS="radeon vesa fbdev virtualbox" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Chances it's in one way or the other a dupe of bug 274771: most likely you need glibc with FEATURES containing "splitdebug".
In response to comment no 2: FEATURES=splitdebug is enabled for glibc at the package level. This does not seem to help. Again 3.6.1 works just fine.
A few more pieces of information: Here is what I get when I search for the symbol strlen in the debug info: # nm /usr/lib/debug/lib/ld-2.13.so.debug | grep str 0001796d t __strerror_r 00019260 t __strnlen 00017ad0 t __strsep 00017ad0 t __strsep_g 00017758 t __strtoul_internal 0001eec8 d capstr 0001d280 r errstring.9206 000084ab t expand_dynamic_string_token 000059fa t local_strdup 0001eec4 d max_capstrlen 0001eec0 d ncapstr 000190f0 t strchr 00019260 t strnlen 00017ad0 t strsep Note that although "strnlen" is present, "strlen" is not. Sure enough, according to the gcc docs, strlen is one of the functions that may be optimized out (an equivalent built-in version is used). http://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/Other-Builtins.html#Other-Builtins If a function is optimized out, there will be no external symbol. I tried to disable the optimization by passing -fno-builtin-strlen in CFLAGS, but this does not seem to work. Perhaps the ebuild ignores or removes some custom CFLAGS. Here is my custom config for glibc cat /etc/portage/env/sys-libs/glibc FEATURES="${FEATURES} splitdebug" CFLAGS="${CFLAGS} -fno-builtin-strlen -g" CXXFLAGS="${CFLAGS}" Apparently, for x86, the presence of debug info for strlen was not strictly necessary in versions < 3.7.0 even though it was for other platforms (e.g. x86_64).
I have access to another gentoo box, this one running on x86_64 rather than x86. The gcc and glibc are the same versions as on the x86 box. Interestingly, I see that strlen has not been optimized out and valgrind 3.7.0 works as expected. The CFLAGS for the x86_64 box are CFLAGS="-march=core2 -O2 -pipe -fno-strict-aliasing" so it would seem that the optimization is less "aggressive". nm /usr/lib/debug/lib64/ld-2.13.so.debug | grep str 0000000000014bb0 t __strerror_r 00000000000162d0 t __strnlen 0000000000014fe0 t __strsep 0000000000014fe0 t __strsep_g 0000000000014e00 t __strtoul_internal 000000000021fdd0 d capstr 000000000001c720 r errstring.10674 00000000000071c0 t expand_dynamic_string_token 0000000000004ce0 t local_strdup 000000000021fdc8 d max_capstrlen 000000000021fdc0 d ncapstr 0000000000016130 t strchr 00000000000161b0 t strcmp 00000000000161e0 t strlen 00000000000162d0 t strnlen 0000000000014fe0 t strsep
> Sure enough, according to the gcc docs, strlen is one of the functions > that may be optimized out (an equivalent built-in version is used). > Nasty! Thanks for doing the leg work on this. I haven't checked, but off the top of my head, does -O0 or -O1 fix this by not optimizing out strlen?
(In reply to comment #6) > > Sure enough, according to the gcc docs, strlen is one of the functions > > that may be optimized out (an equivalent built-in version is used). > > > > Nasty! Thanks for doing the leg work on this. I haven't checked, but off the > top of my head, does -O0 or -O1 fix this by not optimizing out strlen? I tried with just -O0 as optimization flag (removed -march=native). No change, strlen remains absent and valgrind does not work. That said, glibc has to be the most heavily called library ! ... so even if -O0 or -O1 "fixed" the issue, this would not really bean acceptable solution. Ideally, I think the glibc build procedure should be modified so that ld.so (but perhaps not libc itself) gets compiled with the the -fno-builtin-strlen flag enabled. It looks like the CFLAGS actually passed to the glibc build are heavily filtered. It is not even clear to me that -O1 is getting honoured. I have not managed to determine where the filtering occurs, so I am not sure how to proceed to try a fix based on -fno-builtin-strlen.
(In reply to comment #7) > (In reply to comment #6) > > > Sure enough, according to the gcc docs, strlen is one of the functions > > > that may be optimized out (an equivalent built-in version is used). > > > > > > > Nasty! Thanks for doing the leg work on this. I haven't checked, but off the > > top of my head, does -O0 or -O1 fix this by not optimizing out strlen? > > I tried with just -O0 as optimization flag (removed -march=native). No change, > strlen remains absent and valgrind does not work. > > That said, glibc has to be the most heavily called library ! ... so even if > -O0 or -O1 "fixed" the issue, this would not really bean acceptable solution. > > Ideally, I think the glibc build procedure should be modified so that ld.so > (but perhaps not libc itself) gets compiled with the the -fno-builtin-strlen > flag enabled. It looks like the CFLAGS actually passed to the glibc build are > heavily filtered. It is not even clear to me that -O1 is getting honoured. > I have not managed to determine where the filtering occurs, so I am not sure > how to proceed to try a fix based on -fno-builtin-strlen. We'd need some USE flag on glibc to do that. When I have time I'll test to see if compiling glibc with -fno-builtin-strlen resolves the problem before asking the toolchain people do consider that option.
sounds like an issue valgrind peeps need to resolve. this is going to hit every distro, not just Gentoo.
It looks like it has been reported upstream: https://bugs.kde.org/show_bug.cgi?id=286864
I am hitting this problem HARD. Currently, the only way for me to be able to work with Valgrind is to edit glibc ebuild to use flag "-fno-builtin-strlen". I wonder if this can be enabled in glibc ebuild as a flag (like "fix_for_valgrind_mess")
there's no need to edit the ebuild. do something like this: # mkdir -p /etc/portage/env/sys-libs # echo 'CFLAGS+=" -fno-builtin-strlen"' > /etc/portage/env/sys-libs/glibc
In response to (12) In my original report, I mentioned I tried something more or less like what you are suggesting and that it did not work. Either portage or the glibc build system strips the -fno-builtin-strlen flag. For the form, I just tried emerging glibc again, with the exact syntax you suggest, in /etc/portage/env/sys-libs/glibc. It does not work.
What You have to do is: edit /usr/portage/sys-libs/glibc/files/eblits/common.eblit find line saying "append-flags -O2 -fno-strict-aliasing" and change it to "append-flags -O2 -fno-strict-aliasing -fno-builtin-strlen" Then update manifest for ebuild of specific glibc You want to install, install glibc and it's ready to use for valgrind. Also, when reading comments above this line, You'll see why glibc filters out your -O0 or -O1 That said - this needs to be controlled either by useflag on glibc part, or upstream should do something about their bug https://bugs.kde.org/show_bug.cgi?id=286864
(In reply to comment #12) > there's no need to edit the ebuild. do something like this: > # mkdir -p /etc/portage/env/sys-libs > # echo 'CFLAGS+=" -fno-builtin-strlen"' > /etc/portage/env/sys-libs/glibc It won't work, as I found out later - after much digging I found out that EVERY flag possible is stripped and only specific ones are applied. Summing up my comment #14 - either upstream fix, or useflag in glibc ebuild should be implemented.
(In reply to comment #15) > (In reply to comment #12) > > there's no need to edit the ebuild. do something like this: > > # mkdir -p /etc/portage/env/sys-libs > > # echo 'CFLAGS+=" -fno-builtin-strlen"' > /etc/portage/env/sys-libs/glibc > > It won't work, as I found out later - after much digging I found out that EVERY > flag possible is stripped and only specific ones are applied. > > Summing up my comment #14 - either upstream fix, or useflag in glibc ebuild > should be implemented. Or use 3.6.1 which is known stable until upstream resolves the issue. Asking the toolchain folks to add a USE flag on glibc to accomodate one ~arch package where a known stable version exists is excessive. With this bug hitting all the distros, upstream will have to act sooner or later if they want 3.7.0 to every get used.
Sure, I can use 3.6.1 for now. BTW, emerge fails for valgrind-3.6.1 on recent 3.X kernels because of this bug http://bugs.kde.org/show_bug.cgi?id=275278 so an updated ebuild would be useful.
(In reply to comment #17) > Sure, I can use 3.6.1 for now. BTW, emerge fails for valgrind-3.6.1 on recent > 3.X kernels because of this bug > > http://bugs.kde.org/show_bug.cgi?id=275278 > > so an updated ebuild would be useful. Both valgrind-3.6.1-r1 and valgrind-3.6.1-r2 have the r11796 svn patch and build against linux 3.* kernels. They were added on Oct 24 and 27th.
(In reply to comment #18) > Both valgrind-3.6.1-r1 and valgrind-3.6.1-r2 have the r11796 svn patch and > build against linux 3.* kernels. They were added on Oct 24 and 27th. You are correct. My mask meant to block 4.0 was inadvertently blocking 3.6.1-r1 and r2.
Maybe I'm doing something wrong, but I've recompiled glibc-2.14.1-r2 with /etc/portage/env/sys-libs/glibc containing CFLAGS+=" -fno-builtin-strlen" FEATURES="${FEATURES} splitdebug" along with recompiling valgrind 3.7.0-r2 (shouldn't be necessary), AND recompiling my application, and STILL get the error message. I had also tried this with the FEATURES="${FEATURES} splitdebug" in /etc/make.conf, still no joy. Advice? Any way to confirm the options glibc was built with?
(In reply to comment #20) > Maybe I'm doing something wrong, but I've recompiled glibc-2.14.1-r2 with > /etc/portage/env/sys-libs/glibc containing > > CFLAGS+=" -fno-builtin-strlen" > FEATURES="${FEATURES} splitdebug" > > along with recompiling valgrind 3.7.0-r2 (shouldn't be necessary), AND > recompiling my application, and STILL get the error message. > > I had also tried this with the FEATURES="${FEATURES} splitdebug" in > /etc/make.conf, still no joy. > > Advice? Any way to confirm the options glibc was built with? This doesn't work because of comment #15. If you really want -fno-builtin-strlen in there, then you have to follow comment #14. I'm not asking toolchain to add this since upstream should fix the issue and they are aware. You can dump the symbols to see if strlen is in there --- read through the entire bug for examples. BTW, if you do and it works for you, please comment back to this bug. Also, tell us if you set -march, -mcpu or -mtune to any particular value.
After emerging glibc-2.14.1-r2 the configuration described in #20 # ls -l /lib/libc* -rwxr-xr-x 1 root root 1392676 Jan 18 18:27 /lib/libc-2.14.1.so lrwxrwxrwx 1 root root 14 Jan 18 18:27 /lib/libc.so.6 -> libc-2.14.1.so # ls -l /usr/lib/debug/lib/libc-* -rw-r--r-- 1 root root 252374 Jan 18 18:27 /usr/lib/debug/lib/libc-2.14.1.so.debug # nm /usr/lib/debug/lib/libc-2.14.1.so.debug | grep strl 00073560 t __GI_strlen 00075268 t __m128i_strloadu_tolower.clone.1 0007851d T __strlen_g 00073560 t __strlen_ia32 000793e0 t __strlen_sse2 000796c0 t __strlen_sse2_bsf 00073510 i strlen # The 'i' says this is an indirect function, although I'm not clear what that means. Checking 'strcpy' just for comparison, I see it's a 'T', which says there is code in the text section. Check for other 'i' functions, it seems that bcmp, bcopy, bzero, memcmp, memcpy, memmove, mempcpy, memset, strcasestr, strcmp, strcspn, strncmp, strpbrk, strspn and strstr are also indirects. For the compiler flags, I'm running CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" Normally I run -march=pentium4 I'll try the comment #14 patch a little later today.
Following the Comment #14 instructions seem to do the trick. I left all the other parameters the same, modifying only the /usr/portage/sys-libs/glibc/files/eblits/common.eblit file.
(In reply to comment #23) > Following the Comment #14 instructions seem to do the trick. I left all the > other parameters the same, modifying only the > /usr/portage/sys-libs/glibc/files/eblits/common.eblit file. Thanks J.C. We know what the problem is and now I know that you haven't hit a new issue. Hopefully upstream will act before 3.7.0 is stabilized.
I hit this issue even with =dev-util/valgrind-3.6.1-r1. My ld.so.debug has no strlen function, glibc is 2.13-r4. So the only workaround for now is patching glibc ebuild to have -fno-builtin-strlen?
I ran into this last night, found this bug and wondered why valgrind ran on my local machine but not on the server, where I had to debug something. Turns out that on my local box, the "gd" use flag was enabled. I'm not sure what gd does for glibc, but emerging glibc with gd enabled allowed valgrind to run on the server, too. My use flags for working valgrind are: dev-util/valgrind-3.7.0-r3 USE="-mpi" 0 kB sys-libs/glibc-2.14.1-r3 USE="gd (multilib) -debug -glibc-omitfp (-hardened) -profile (-selinux) -vanilla" 0 kB s.
(In reply to comment #26) > I ran into this last night, found this bug and wondered why valgrind ran on > my local machine but not on the server, where I had to debug something. > Turns out that on my local box, the "gd" use flag was enabled. > > I'm not sure what gd does for glibc, but emerging glibc with gd enabled > allowed valgrind to run on the server, too. > > My use flags for working valgrind are: > > dev-util/valgrind-3.7.0-r3 USE="-mpi" 0 kB > sys-libs/glibc-2.14.1-r3 USE="gd (multilib) -debug -glibc-omitfp > (-hardened) -profile (-selinux) -vanilla" 0 kB > > s. seems to be unrelated on my machine, recompiling with +gd doesn't help.
Unlike mentioned in #214065, valgrind 3.6.1 is affected. I put a question upstream: https://bugs.kde.org/show_bug.cgi?id=286864#c3
It would seem the problem will get even bigger shortly, at least if I'm reading one of the later points of http://gcc.gnu.org/gcc-4.7/changes.html, section "General Optimizer Improvements".
*** Bug 413603 has been marked as a duplicate of this bug. ***
Oh, that's damn wornedrful: I can't use 3.6.1-r3 because of glibc-2.15 being unsupported and I can't use 3.7.0-r4, because glibc lacks strlen... Now the only option is to hack glibc's eblit and keep patched version in sync for ages... What a mess...
(In reply to comment #31) > Oh, that's damn wornedrful: I can't use 3.6.1-r3 because of glibc-2.15 being > unsupported and I can't use 3.7.0-r4, because glibc lacks strlen... > > Now the only option is to hack glibc's eblit and keep patched version in > sync for ages... What a mess... *valgrind-3.6.1-r4 (25 Jul 2012) 25 Jul 2012; Anthony G. Basile <blueness@gentoo.org> +valgrind-3.6.1-r4.ebuild, +files/valgrind-3.6.1-glibc-2.15.patch: Allow valgrind-3.6.1 to build against glibc-2.15 so Andrew doesn't yell at me, bug #390323 comment #31
*** Bug 431970 has been marked as a duplicate of this bug. ***
(In reply to comment #33) > *** Bug 431970 has been marked as a duplicate of this bug. *** The undefined strlen problem persists into 3.8.0.
*** Bug 214065 has been marked as a duplicate of this bug. ***
*** Bug 274771 has been marked as a duplicate of this bug. ***
Note there is an upstream bug report for this: https://bugs.kde.org/show_bug.cgi?id=190429
Hey, can someone enlighten me please, if there is a workaround other than editing the /usr/portage/sys-libs/glibc/files/eblits/common.eblit ? I believe i tried every suggestion made here and a couple of others, no dice. The weird thing is i have a couple of installations with cat /etc/portage/env/sys-libs/glibc FLAGS="${CFLAGS} -ggdb" FEATURES="${FEATURES} splitdebug" and nothing done to the eblit or ebuilds and it works. Same arch (x86-64), (by now) same gcc (tried 4.5.4 and 4.6.3), same glibc version (2.15.3). One works, one doesn't. What else could be different?
(In reply to comment #38) > Hey, can someone enlighten me please, if there is a workaround other than > editing the /usr/portage/sys-libs/glibc/files/eblits/common.eblit ? > I believe i tried every suggestion made here and a couple of others, no dice. > The weird thing is i have a couple of installations with > > cat /etc/portage/env/sys-libs/glibc > FLAGS="${CFLAGS} -ggdb" > FEATURES="${FEATURES} splitdebug" > > and nothing done to the eblit or ebuilds and it works. Same arch (x86-64), > (by now) same gcc (tried 4.5.4 and 4.6.3), same glibc version (2.15.3). One > works, one doesn't. What else could be different? Dudka's suggestion from upstream, to compile glibc with -fno-builtin-strlen, is the current working solution. Its implementation in gentoo is comment #12. Why you aren't hitting it, I don't know, but look at comment #4 for how you can check for strlen symbol.
As was written in #15, the solution in #12 does not work. Upstream does not seem to care, maybe because it is basically gcc that is compiling the glibc in a way that it does not work with valgrind. Before reading the comments I wanted to propose a USE flag for this case, but I understand your problem. How about just not stripping -fno-builtin-strlen (or future proof: -fno-builtin*) from the CFLAGS? This way we do not have that much overhead, and we can use the solution from #12. A nicer solution might be to add -fno-builtin-strlen to the safe flags, therefore not stripping it. (There are already a few -fno* flags in there so it would fit nicely) Since it only disables a new optimization it should be safe to do so?
(In reply to comment #40) > As was written in #15, the solution in #12 does not work. > > Upstream does not seem to care, maybe because it is basically gcc that is > compiling the glibc in a way that it does not work with valgrind. This is basically valgrind using symbol reference it should not use. Aside from fixing valgirnd, the only solution is to disable builtin strlen, but doin this in glibc will really hamper performance and should be done as a last resort only.
Actual upstream bug appears to be https://bugs.kde.org/show_bug.cgi?id=286864
Why not to add a patch from the upstream bug: http://bugsfiles.kde.org/attachment.cgi?id=82043 ? Works fine here and I'm finally able to use valgrind on one of my ~amd64 boxes.
(In reply to Andrew Savchenko from comment #43) > Why not to add a patch from the upstream bug: > http://bugsfiles.kde.org/attachment.cgi?id=82043 > ? > > Works fine here and I'm finally able to use valgrind on one of my ~amd64 > boxes. Works fine over here too.
I'm seeing valgrind-3.9.0 with glibc-2.19-r1 working fine (not encountering this bug), was a workaround added to the ebuild or a was this fixed upstream?
At least with valgrind-3.9.0. and glibc-2.19 the bug is till here. I haven't tried 2.19-r1, thought. But be aware that this bug is floating and it may or may not appear on different setup with apparently similar configuration.
(In reply to Andrew Savchenko from comment #46) > But be aware that this bug is floating and it may or > may not appear on different setup with apparently similar configuration. Does this depend on FEATURES=nostrip (for sys-libs/glibc) eventually too? Got it work here with this hack: # cat /etc/portage/profile/profile.bashrc if [[ ${CATEGORY}/${PN} == 'sys-libs/glibc' ]]; then FEATURES="${FEATURES} nostrip" fi
Technically, I got a new problem, but it's the same anyways, so I'll just hijack this bug :P dev-util/valgrind-3.10.1 fails on sys-libs/glibc-2.20-r2 - strlen ... $ strace -o valgrind.strace /usr/bin/valgrind /bin/ls [... known error message about strlen in ld-linux-x86-64.so.2 ...] $ ls -l /lib/ld-linux-x86-64.so.2 lrwxrwxrwx 1 root root 10 19. Jul 08:00 /lib/ld-linux-x86-64.so.2 -> ld-2.20.so $ grep debug valgrind.strace | grep -v ENOENT open("/usr/lib/debug/lib64/ld-2.20.so.debug", O_RDONLY) = 4 $ nm /usr/lib/debug/lib64/ld-2.20.so.debug | grep "\<strlen" 0000000000018ad0 t strlen sys-libs/glibc gd USE flag already in effect. Reemerged glibc with suggested append-flags -O2 -fno-strict-aliasing -fno-builtin-strlen in /var/cache/portage/tree/sys-libs/glibc/files/eblits/common.eblit - no change Even more shitty is now, that I can't even downgrade valgrind: # emerge -1 =dev-util/valgrind-3.9.0 configure: error: Valgrind requires glibc version 2.2 - 2.17 # emerge -1 =dev-util/valgrind-3.9.0 "<sys-libs/glibc-2.18" * Sanity check to keep you from breaking your system: * Downgrading glibc is not supported and a sure way to destruction nice ...
(In reply to Bodo Thiesen from comment #48) > Technically, I got a new problem, but it's the same anyways, so I'll just > hijack this bug :P > > dev-util/valgrind-3.10.1 fails on sys-libs/glibc-2.20-r2 - strlen ... I just got an intuition to test dropping installsources from FEATURES. Now valgrind works again. Having compressdebug in FEATURES is no problem.
(In reply to Bodo Thiesen from comment #49) > (In reply to Bodo Thiesen from comment #48) >> dev-util/valgrind-3.10.1 fails on sys-libs/glibc-2.20-r2 - strlen ... > dropping installsources from FEATURES. Now valgrind works again. > Having compressdebug in FEATURES is no problem. And -fno-builtin-strlen is still needed in common.eblit.
still a problem, glibc has a custom-cflags useflag that makes the file /etc/portage/env/sys-libs/glibc from comment #4 work
A patched valgrind-3.15.0-r1 is available in my overlay: https://github.com/stefantalpalaru/gentoo-overlay The patch simply removes all checks for a "strlen" symbol: https://github.com/stefantalpalaru/gentoo-overlay/commit/558048b43a17a2b5163295683e9a201ae9757962#diff-196a07cd7608fa13838a2697f1cc11f2
commit 4569f05afae6d9fea70cb9982c694f1fdca38622 Author: Eli Schwartz <eschwartz93@gmail.com> Date: Tue Dec 26 23:14:50 2023 -0500 sys-libs/glibc: disable stripping for ld.so as well Similar to how pthread must not be stripped in order to avoid breaking gdb, ld.so must not be stripped in order to avoid breaking valgrind. Closes: https://bugs.gentoo.org/920753 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> I suspect the now-non-stripped symtab fixes this.
Ah, wait, no, sorry, I'm confusing this with another one.
