Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 274771 - dev-util/valgrind: huge amount of errors with >=glibc-2.10
Summary: dev-util/valgrind: huge amount of errors with >=glibc-2.10
Status: RESOLVED DUPLICATE of bug 390323
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: AMD64 Linux
: High major (vote)
Assignee: Anthony Basile
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 264558
  Show dependency tree
 
Reported: 2009-06-20 08:39 UTC by Nikos Chantziaras
Modified: 2012-09-14 11:30 UTC (History)
25 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
valgrind ldd (error,188.11 KB, text/plain)
2009-06-20 08:40 UTC, Nikos Chantziaras
Details
emerge --info (emerge--info,4.11 KB, text/plain)
2009-06-20 08:40 UTC, Nikos Chantziaras
Details
valgrind-9999.ebuild (valgrind-9999.ebuild,2.81 KB, text/plain)
2009-08-11 15:19 UTC, Nikos Chantziaras
Details
Allows valgrind to search debuginfo files into /usr/lib/debug/libXX (valgrind_fix_debuginfo_path_on_gentoo.patch,1.69 KB, patch)
2009-11-04 01:06 UTC, Vincenzo Di Massa
Details | Diff
emerge --info (emergeinfo.txt,5.96 KB, text/plain)
2010-11-12 13:34 UTC, Stephan Menzel
Details
My emerge info (emerge--info.txt,3.53 KB, text/plain)
2010-11-12 21:38 UTC, Anthony Basile
Details
My emerge --info (emerge--info.txt,5.79 KB, text/plain)
2010-12-29 11:21 UTC, Oleg
Details
My emerge --info (file_274771.txt,5.23 KB, text/plain)
2012-05-11 07:11 UTC, Ilia Pozhilov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikos Chantziaras 2009-06-20 08:39:24 UTC
(Blocks bug 264558, per request by SpanKY: http://bugs.gentoo.org/show_bug.cgi?id=264558#c20 )

On AMD64 (and only on AMD64) I get a long list of errors with *any* executable in valgrind.  For example "valgrind ls" or "valgrind ldd" (ldd is a static executable).  Or anything else.  This is with glibc-2.10.1.

Valgrind can't cope with the new, sse-optimized strlen function of glibc 2.10.1 on amd64.  Fedora is applying a patch for this:

  valgrind-3.4.1-x86_64-ldso-strlen.patch

as well as another, glibc 2.10.1 specific one:

  valgrind-3.4.1-glibc-2.10.1.patch

Those patches can be found at:

  http://cvs.fedoraproject.org/viewvc/rpms/valgrind/F-11

However, the strlen patch (the one we need) does not work with Gentoo unless glibc is emerged with debug symbols enabled:

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-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:
valgrind:  Possible fix: install glibc's debuginfo package on this machine.
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.

I'm attaching the errors and my emerge --info.
Comment 1 Nikos Chantziaras 2009-06-20 08:40:16 UTC
Created attachment 195254 [details]
valgrind ldd
Comment 2 Nikos Chantziaras 2009-06-20 08:40:32 UTC
Created attachment 195256 [details]
emerge --info
Comment 3 Henning Rogge 2009-07-12 12:39:34 UTC
A SVN version of valgrind (revision 10418) is working find with glibc 2.10.1 on AMD64.
Comment 4 Some stupid real name 2009-07-16 07:14:47 UTC
(In reply to comment #3)
> A SVN version of valgrind (revision 10418) is working find with glibc 2.10.1 on
> AMD64.

Unfortunately, SVN revision 10480 doesn't work with the same glibc on AMD64. Running valgrind ls shows tons of errors.

Comment 5 Some stupid real name 2009-07-16 07:40:19 UTC
Edit: SVN 10418 or 10419 doesn't even compile anymore due to undefined LibVEX_version. Also, I could have read it wrong but it seems that Valgrind developers gave up on this or similar issue on ppc platform:

https://bugs.kde.org/show_bug.cgi?id=182474 (bottom commend)
Comment 6 Maurice van der Pot (RETIRED) gentoo-dev 2009-07-26 12:08:13 UTC
I added valgrind-3.4.1-r1 that includes both patches as well as the same warning message for amd64 that was already present for ppc before.

People will just have to emerge libc with splitdebug to not have any problems with valgrind.
Comment 7 Nikos Chantziaras 2009-08-02 03:22:49 UTC
(In reply to comment #6)
> I added valgrind-3.4.1-r1 that includes both patches as well as the same
> warning message for amd64 that was already present for ppc before.
> 
> People will just have to emerge libc with splitdebug to not have any problems
> with valgrind.

I just emerged glibc with splitdebug enabled (it produced *.debug files in /usr/lib64/debug) but it still doesn't work. I always get:

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-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:
valgrind:  Possible fix: add splitdebug to FEATURES in make.conf and remerge glibc.
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.

So I'm reopening.
Comment 8 Zeev Tarantov 2009-08-07 11:25:38 UTC
It's looking at the right place, the symbol is there, it's not finding it.

wolf@wolfpc ~ $ emerge -pv glibc valgrind

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-libs/glibc-2.10.1  USE="(multilib) nls -debug -gd -glibc-omitfp (-hardened) -profile (-selinux) -vanilla" 0 kB
[ebuild   R   ] dev-util/valgrind-3.4.1-r1  USE="-mpi" 0 kB

Total: 2 packages (2 reinstalls), Size of downloads: 0 kB

wolf@wolfpc ~ $ valgrind -v true                                                       
==22091== Memcheck, a memory error detector.                                           
==22091== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.              
==22091== Using LibVEX rev 1884, a library for dynamic binary translation.             
==22091== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.                    
==22091== Using valgrind-3.4.1, a dynamic binary instrumentation framework.            
==22091== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.              
==22091==                                                                              
--22091-- Command line                                                                 
--22091--    true                                                                      
--22091-- Startup, with flags:                                                         
--22091--    -v                                                                        
--22091-- Contents of /proc/version:                                                   
--22091--   Linux version 2.6.31-rc5 (wolf@wolfpc) (gcc version 4.4.1 (Gentoo 4.4.1 p1.0) ) #4 SMP Wed Aug 5 08:06:29 IDT 2009
--22091-- Arch and hwcaps: AMD64, amd64-sse2                                                                                  
--22091-- Page sizes: currently 4096, max supported 4096                                                                      
--22091-- Valgrind library directory: /usr/lib64/valgrind                                                                     
--22091-- Reading syms from /bin/true (0x400000)                                                                              
--22091--    object doesn't have a symbol table                                                                               
--22091-- Reading syms from /usr/lib64/valgrind/amd64-linux/memcheck (0x38000000)                                             
--22091-- Reading debug info from /usr/lib/debug/usr/lib64/valgrind/amd64-linux/memcheck.debug ..                             
--22091--    object doesn't have a dynamic symbol table                                                                       
--22091-- Reading syms from /lib64/ld-2.10.1.so (0x3637200000)                                                                
--22091-- Reading debug info from /usr/lib/debug/lib64/ld-2.10.1.so.debug ..                                                  

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-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:
valgrind:  Possible fix: add splitdebug to FEATURES in make.conf and remerge glibc.
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.

wolf@wolfpc ~ $ nm /usr/lib/debug/lib64/ld-2.10.1.so.debug | grep ' strlen'
0000000000015800 t strlen

wolf@wolfpc ~ $ emerge --info
Portage 2.1.6.13 (default/linux/amd64/2008.0/desktop, gcc-4.4.1, glibc-2.10.1-r0, 2.6.31-rc5 x86_64)
=================================================================
System uname: Linux-2.6.31-rc5-x86_64-Intel-R-_Core-TM-2_Duo_CPU_E6550_@_2.33GHz-with-gentoo-2.0.1
Timestamp of tree: Fri, 07 Aug 2009 05:15:02 +0000
app-shells/bash:     4.0_p28
dev-java/java-config: 2.1.8-r1
dev-lang/python:     2.6.2-r1, 3.1
dev-util/cmake:      2.6.4-r2
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.4.3-r3
sys-apps/sandbox:    2.0
sys-devel/autoconf:  2.13, 2.63-r1
sys-devel/automake:  1.7.9-r1, 1.9.6-r2, 1.10.2, 1.11
sys-devel/binutils:  2.19.1-r1
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6a
virtual/os-headers:  2.6.30-r1
ACCEPT_KEYWORDS="amd64 ~amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-g -O2 -pipe -march=core2 -momit-leaf-frame-pointer"
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/share/config"
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/terminfo /etc/udev/rules.d"
CXXFLAGS="-g -O2 -pipe -march=core2 -momit-leaf-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks fixpackages installsources parallel-fetch protect-owned sandbox sfperms splitdebug strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://mirror.hamakor.org.il/pub/mirrors/gentoo/ "
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
LINGUAS="en en_US"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
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="/usr/local/portage/layman/java-overlay /usr/local/portage/layman/gcc-porting /usr/local/portage/layman/mozilla /usr/local/portage"
SYNC="rsync://mirror.hamakor.org.il/gentoo-portage"
USE="X acl acpi alsa amd64 bash-completion bidi bluetooth branding bzip2 cairo cdr cli cracklib crypt dbus dri dvd dvdr eds emboss encode evo fam firefox gif gpm gstreamer gtk hal iconv ipv6 isdnlog jpeg kde libnotify mad mikmod mmx mp3 mpeg mudflap multilib ncurses nls nptl nptlonly ogg opengl openmp pch pcre pdf perl png ppds pppd python qt3 qt3support qt4 quicktime readline reflection sdl session spell spl sqlite3 sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype unicode usb vorbis xcb xcomposite xml xorg xulrunner xv zlib" ALSA_CARDS="hda-intel" 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 authn_alias authn_anon 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 deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="stv0680" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US" SANE_BACKENDS="niash stv680" USERLAND="GNU" VIDEO_CARDS="nv nvidia"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 9 Zeev Tarantov 2009-08-07 15:21:34 UTC
Upstream bug:
http://bugs.kde.org/show_bug.cgi?id=190429

Upstream commit mentioned in http://bugs.kde.org/show_bug.cgi?id=190429#c11:
http://sourceforge.net/mailarchive/forum.php?thread_name=20090802122132.B1F9E10887D@jail0086.vps.exonetric.net&forum_name=valgrind-developers

The upstream SVN refuses to talk to me, and the commit in the mailing list doesn't apply cleanly. I've applied it manually and it doesn't work. Maybe a previous change (like the one that adds "DebugInfo_get_soname") is required. When I'll manage to check out the code from upstream repository I'll test that and report here.
Comment 10 Zeev Tarantov 2009-08-08 01:32:16 UTC
valgrind built manually (without portage) from svn checkout (r10754) works.

$ /usr/local/bin/valgrind -v true
==6515== Memcheck, a memory error detector.             
==6515== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==6515== Using Valgrind-3.5.0.SVN and LibVEX; rerun with -h for copyright info
==6515== Command: true                                                        
==6515==                                                                      
--6515-- Valgrind flags:                                                      
--6515--    -v                                                                
--6515-- Contents of /proc/version:
--6515--   Linux version 2.6.31-rc5 (wolf@wolfpc) (gcc version 4.4.1 (Gentoo 4.4.1 p1.0) ) #4 SMP Wed Aug 5 08:06:29 IDT 2009
--6515-- Arch and hwcaps: AMD64, amd64-sse3-cx16
--6515-- Page sizes: currently 4096, max supported 4096
--6515-- Valgrind library directory: /usr/local/lib/valgrind
--6515-- Reading syms from /bin/true (0x400000)
--6515--    object doesn't have a symbol table
--6515-- Reading syms from /usr/local/lib64/valgrind/memcheck-amd64-linux (0x38000000)
--6515--    object doesn't have a dynamic symbol table
--6515-- Reading syms from /lib64/ld-2.10.1.so (0x3662200000)
--6515-- Reading debug info from /usr/lib/debug/lib64/ld-2.10.1.so.debug ..
--6515-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
--6515-- REDIR: 0x3662215800 (strlen) redirected to 0x3803f647 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--6515-- Reading syms from /usr/local/lib64/valgrind/vgpreload_core-amd64-linux.so (0x4802000)
--6515-- Reading syms from /usr/local/lib64/valgrind/vgpreload_memcheck-amd64-linux.so (0x4a04000)
==6515== WARNING: new redirection conflicts with existing -- ignoring it
--6515--     new: 0x3662215800 (strlen              ) R-> 0x04a085d0 strlen
--6515-- REDIR: 0x3662215750 (index) redirected to 0x4a08320 (index)
--6515-- REDIR: 0x36622157d0 (strcmp) redirected to 0x4a088d0 (strcmp)
--6515-- Reading syms from /lib64/libc-2.10.1.so (0x3662800000)
--6515-- Reading debug info from /usr/lib/debug/lib64/libc-2.10.1.so.debug ..
--6515-- REDIR: 0x366287a840 (rindex) redirected to 0x4a08180 (rindex)
--6515-- REDIR: 0x3662879f30 (strcmp) redirected to 0x4a08880 (strcmp)
--6515-- REDIR: 0x366287a4c0 (strlen) redirected to 0x4a08590 (strlen)
--6515-- REDIR: 0x366287a690 (strncmp) redirected to 0x4a08810 (strncmp)
--6515-- REDIR: 0x3662879eb0 (index) redirected to 0x4a08220 (index)
--6515-- REDIR: 0x366287fb20 (strchrnul) redirected to 0x4a09520 (strchrnul)
--6515-- REDIR: 0x3662876810 (malloc) redirected to 0x4a07491 (malloc)
--6515-- REDIR: 0x3662876730 (free) redirected to 0x4a070a1 (free)
--6515-- REDIR: 0x366287d3a0 (memcpy) redirected to 0x4a089a0 (memcpy)
--6515-- REDIR: 0x366287d050 (stpcpy) redirected to 0x4a091d0 (stpcpy)
==6515==
==6515== HEAP SUMMARY:
==6515==     in use at exit: 0 bytes in 0 blocks.
==6515==   total heap usage: 29 allocs, 29 frees, 3,897 bytes allocated.
==6515==
==6515== All heap blocks were freed -- no leaks are possible.
==6515==
==6515== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
--6515--
--6515-- used_suppression:      4 dl-hack3-cond-1
==6515==
==6515== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
Comment 11 Maurice van der Pot (RETIRED) gentoo-dev 2009-08-08 15:29:26 UTC
Then i suspect there must be something else that solves the problem for you. As far as I can tell the only significant difference between that patch and the one in portage is that it makes the redir non-mandatory for glibc < 2.10.

Could you try replacing our ldso-strlen patch with the one from upstream? You'll have to get rid of the last hunk in the patch (taken from svn diff -r10688:10689), because it's irrelevant and fails to apply.

The only noticeable difference between your system and mine seems to be gcc-4.4. If you still have 4.3 installed it may be worth it to remerge glibc with that and see what happens.
Comment 12 Zeev Tarantov 2009-08-11 12:42:52 UTC
I said I did apply the upstream patch instead, it didn't work.

I looked at the commit log (thought it's big, six months of development) and applied r8959 and r9329 (in modified form to fit without the intermediate steps) because they seemed likely to affect a function override in a prelinked shared object based on split debug info in dwarf format, but still no go.

I don't know how recompiling glibc with gcc-4.3 will help - after all, the upstream trunk version of valgrind works with my glibc. I just don't know which combination of commits in those six months does the trick. I think I'll use the valgrind I built without portage and wait for 3.5 to be out. Or, if someone makes a live ebuild.

I have the upstream repo in git (with full history) and can probably send it to you if upstream svn gives you trouble.
Comment 13 Nikos Chantziaras 2009-08-11 15:19:53 UTC
Created attachment 200938 [details]
valgrind-9999.ebuild

Current SVN works here OK too.  Here's a live ebuild which can be used as a temporary work-around until 3.5 is out.
Comment 14 Eric Womer 2009-08-16 18:52:21 UTC
(In reply to comment #13)
> Created an attachment (id=200938) [edit]
> valgrind-9999.ebuild
> 
> Current SVN works here OK too.  Here's a live ebuild which can be used as a
> temporary work-around until 3.5 is out.
> 

Did not fix the issue for me

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-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.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.
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.


Comment 15 Christian Ruppert (idl0r) gentoo-dev 2009-08-16 18:59:36 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > Created an attachment (id=200938) [edit]
> > valgrind-9999.ebuild
> > 
> > Current SVN works here OK too.  Here's a live ebuild which can be used as a
> > temporary work-around until 3.5 is out.
> > 
> 
> Did not fix the issue for me
> 
> 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-x86-64.so.2
> valgrind:  was not found whilst processing
> valgrind:  symbols from the object with soname: ld-linux-x86-64.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.
> valgrind:
> valgrind:  Cannot continue -- exiting now.  Sorry.
> 

Works fine for me, You've just to install glibc with FEATURES=splitdebug.
Comment 16 Nikos Chantziaras 2009-08-19 23:09:05 UTC
Valgrind 3.5.0 has just been released.
Comment 17 Bernd Buschinski 2009-08-23 15:07:50 UTC
I emerged glibc with splitdebug on my laptop (core2duo) and desktop maschine (phenom), it works fine on my laptop, but the issue is still present on my desktop. Both ~amd64, gcc-4.4.1 and (beside from march) same cflags
valgrind-9999 does not help
Comment 18 Maurice van der Pot (RETIRED) gentoo-dev 2009-10-30 18:26:12 UTC
Bernd, doesn't 3.5.0 work for you?
Comment 19 Vincenzo Di Massa 2009-11-03 15:30:02 UTC
(In reply to comment #18)
> Bernd, doesn't 3.5.0 work for you?
> 

It does not work for me as well, I compiled glibc with splitdebug an installed valgrind 3.5... without success.

Any advice?

Vinenzo
Comment 20 Vincenzo Di Massa 2009-11-04 01:06:20 UTC
Created attachment 209182 [details, diff]
Allows valgrind to search debuginfo files into /usr/lib/debug/libXX

I think a runtime check for determining the arch is fine, but maybe a compile time one could be desired.
For users who don't want to fix valgrind a quick and dirty hack is to symlink /usr/lib/debug/libXX to /usr/lib/debug/lib/.

This fixes the problem for me.
Comment 21 Fabio Erculiani (RETIRED) gentoo-dev 2009-11-06 20:34:06 UTC
I ask everybody, if running 64bit multilib systems (and report if not but you are running into this issue anyway), to post the following command output:

  $ file /usr/lib*

Thanks
Comment 22 Manfred Knick 2009-11-08 16:30:45 UTC
(In reply to comment #21)

#  file /usr/lib*
/usr/lib:     symbolic link to `lib64'
/usr/lib32:   directory
/usr/lib64:   directory
/usr/libexec: directory

( Phenom X4 )
Comment 23 Casey Jones 2009-11-21 05:44:27 UTC
(In reply to comment #22)
> (In reply to comment #21)
> 
> #  file /usr/lib*
> /usr/lib:     symbolic link to `lib64'
> /usr/lib32:   directory
> /usr/lib64:   directory
> /usr/libexec: directory
> 
> ( Phenom X4 )
> 

I've got the same output, and an Athlon II X4
Comment 24 Philip Allison 2009-11-24 09:18:44 UTC
I'm having the same problem - very frustrating, since I'm trying to use valgrind and work to help check the quality of new code.

As per comment 21:

philip@gridbug(0)debug $ file /usr/lib*
/usr/lib:     symbolic link to `lib64'
/usr/lib32:   directory
/usr/lib64:   directory
/usr/libexec: directory

However, I don't think any amount of symlinking will get around the issue, the strlen symbol just doesn't seem to be there in the debuginfo for the 64-bit ld.so:

philip@gridbug(128)debug $ find -type f -exec strings -f {} \; | grep strlen
./lib32/ld-2.10.1.so.debug: max_capstrlen
./lib32/ld-2.10.1.so.debug: strlen
strings: ./usr/lib32/misc/glibc/pt_chown.debug: Permission denied
strings: ./usr/lib64/misc/glibc/pt_chown.debug: Permission denied
./lib64/ld-2.10.1.so.debug: max_capstrlen
Comment 25 Zeev Tarantov 2009-11-24 12:02:33 UTC
A shot in the dark, but there were issues with debugedit recently. Try to re-emerge dev-libs/beecrypt, dev-util/debugedit, glibc. I'm now using sys-libs/glibc-2.11 and it works great with dev-util/valgrind-3.5.0.

$ nm /usr/lib/debug/lib64/ld-2.11.so.debug | grep ' strlen'
0000000000016530 t strlen
Comment 26 Philip Allison 2009-11-27 09:26:55 UTC
I don't have debugedit installed.  What do you have installed that depends on it?
Comment 27 Zeev Tarantov 2009-11-27 13:46:52 UTC
FEATURES="installsources"
Comment 28 Philip Allison 2009-11-28 18:28:49 UTC
That's a different matter.  I don't want/need the source of glibc installed - I don't want to debug glibc, just programs compiled against it.  I haven't needed either "installsources" or "splitdebug" with previous versions of valgrind/glibc.
Comment 29 Nikos Chantziaras 2009-12-03 23:29:09 UTC
(In reply to comment #28)
> I haven't needed either "installsources" or "splitdebug" with previous
> versions of valgrind/glibc.

You need at least splitdebug now.
Comment 30 Maurice van der Pot (RETIRED) gentoo-dev 2009-12-04 19:45:44 UTC
To summarize:
- you need to have emerged glibc with splitdebug in FEATURES in make.conf
- /usr/lib should be a symlink to /usr/lib64 and not the other way around

I can't figure out what is going wrong without being able to reproduce it.

If you're still seeing this problem despite the above conditions, and if you're able to do some debugging yourself, please share any information you find that can help determine the root cause.

Alternatively you can also contact the upstream developers either through their bugzilla (https://bugs.kde.org/enter_valgrind_bug.cgi) or through the mailing lists (http://valgrind.org/support/mailing_lists.html).

RESOLVED/FIXED+INVALID+WORKSFORME+NEEDINFO+UPSTREAM
Comment 31 Philip Allison 2009-12-08 22:17:09 UTC
In my case, /usr/lib *is* a symlink to /usr/lib64, and I *did* emerge glibc with "splitdebug".  I don't want or need to use "installsources" and emerge debugedit, because it isn't glibc itself that I'm trying to debug.  The part I don't understand is why there is *no strlen symbol anywhere in the 64-bit glibc's debug info* (especially when it's still there in the 32-bit version).  No version of Valgrind is going to work correctly with a version of glibc where that is the case!

FWIW, I upgraded to glibc 2.11, which seems to have a strlen symbol in the debug info again.  I would love to help further, but I don't have time to downgrade again and continue playing - as I said before, I'm using Valgrind for work purposes.

Perhaps strlen is forcibly inlined with 2.10 in certain conditions?
Comment 32 Marek Zachara 2010-03-11 18:08:40 UTC
Apparently, glibc build shouldnt be splitted and glibc ebuild specifically prevents that with RESTRICT="strip" as per http://bugs.gentoo.org/46186
so splitdebug is not a solution here
Comment 33 Maurice van der Pot (RETIRED) gentoo-dev 2010-03-17 17:19:57 UTC
(In reply to comment #32)
> http://bugs.gentoo.org/46186

The problem mentioned there has nothing to do with this bug report.
Comment 34 David Flogeras 2010-05-18 19:13:50 UTC
Has anyone seen this rear up again? I am running a (mostly) amd64 machine, with ~amd64 valgrind (3.5.0).  This was working when I was debugging a lot in the winter. I just tried to do 'valgrind ls', and get the same output as comment #7. I have recompiled both glibc and valgrind to no avail.

I have yet to try "splitdebug" et al. but it seems that this is not necessarily the solution?
Comment 35 Christian Ruppert (idl0r) gentoo-dev 2010-05-18 19:20:19 UTC
(In reply to comment #34)
> I have yet to try "splitdebug" et al. but it seems that this is not necessarily
> the solution?
> 

splitdebug is still necessary in order to work properly
Comment 36 Stefan Oswald 2010-06-02 14:21:27 UTC
Another solution:

mkdir -p /etc/portage/env/sys-libs
echo FEATURES=\"nostrip\" > /etc/portage/env/sys-libs/glibc
emerge -1v sys-libs/glibc
Comment 37 Stephan Menzel 2010-06-15 08:52:06 UTC
So just to clarify this: setting FEATURE "splitdebug" should solve this? Because in my case it doesn't. 

I have set this and the issue remains. Is there anything else one could do?

Cheers,
Stephan
Comment 38 Zeev Tarantov 2010-06-15 12:23:43 UTC
RE: comment #37, did you recompile glibc after setting FEATURE="splitdebug"? This feature produces separate ELF files (shared objects) with the symbol table for the binaries, while they are compiled / installed. glibc must be built with debug symbols (-g in CFLAGS) and valgrind must be able to find those symbols, either in the shared objects themselves or in a separate file pointed to by .gnu_debuglink.

What is your libc? Something like:
$ which true
/bin/true

$ ldd /bin/true
        linux-vdso.so.1 =>  (0x00007fff423ff000)
        libc.so.6 => /lib/libc.so.6 (0x0000003d9ee00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003d9ea00000)

So libc is /lib/libc.so.6

$ ll /lib/libc.so.6
lrwxrwxrwx 1 root root 14 Jun 11 13:47 /lib/libc.so.6 -> libc-2.11.2.so

Real file.

$ objdump -t /lib/libc-2.11.2.so

/lib/libc-2.11.2.so:     file format elf64-x86-64

SYMBOL TABLE:
no symbols

So if we look at the binary, there is no way to tell where some function is. All we have is a big .text section of code. We need the offset of malloc!

But, maybe a separate file has the symbols?

$ objdump -s -j .gnu_debuglink /lib/libc-2.11.2.so

/lib/libc-2.11.2.so:     file format elf64-x86-64

Contents of section .gnu_debuglink:
 0000 6c696263 2d322e31 312e322e 736f2e64  libc-2.11.2.so.d
 0010 65627567 00000000 65c52829           ebug....e.()    

Aha! a file libc-2.11.2.so.debug with crc32 of 0x65c52829 has the symbols.
Where is it? Under /usr/lib/debug/$(lib_dir)/debug_file_name.

So:

$ objdump -t /usr/lib/debug/lib64/libc-2.11.2.so.debug | egrep ' malloc$'

0000000000076d10 g     F .text  0000000000000257 malloc

Now we know offset of malloc. So we can see calls to malloc to patch them.
Comment 39 Stephan Menzel 2010-06-15 15:18:09 UTC
OK, I have tried all sorts of combinations now I can think of. To no avail. I have "splitdebug" with or without "nostrip" and several combinations of -g and -ggdb in my CFLAGS.

Here's what I think would be relevant:

It is an ~amd64 box with all current ebuilds. No overlays or any special customization.

sm@nt468 ~ $ ldd /bin/ls
        linux-vdso.so.1 =>  (0x00007fffb0bff000)
        librt.so.1 => /lib/librt.so.1 (0x00007f5f7d4ac000)
        libacl.so.1 => /lib/libacl.so.1 (0x00007f5f7d2a5000)
        libc.so.6 => /lib/libc.so.6 (0x00007f5f7cf58000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f5f7cd3d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5f7d6b4000)
        libattr.so.1 => /lib/libattr.so.1 (0x00007f5f7cb38000)
sm@nt468 ~ $ ll /lib/libc.so.6
lrwxrwxrwx 1 root root 14 15. Jun 16:56 /lib/libc.so.6 -> libc-2.11.2.so

sm@nt468 ~ $ objdump -t /lib/libc-2.11.2.so |grep strlen
0000000000078480 l     F .text  0000000000000045              __GI_strlen
0000000000078480 g     F .text  0000000000000045              strlen

(the command issues lots and lots of .text symbols)

sm@nt468 ~ $ objdump -s -j .gnu_debuglink /lib/libc-2.11.2.so

/lib/libc-2.11.2.so:     file format elf64-x86-64

(no .gnu_debuglink section, that's it.)

So I have to assume that despite all my efforts to change that and all my rebuilds, glibc has no debug symbols at all, right? Or if it does, it's split away and valgrind can't find it.

here's my make.conf:

CFLAGS="-O3 -pipe -g -march=native -mtune=native"
CXXFLAGS="-O3 -pipe -g -march=native -mtune=native"
CHOST="x86_64-pc-linux-gnu"
USE="3dnow 3dnowext 64bit admin administrator adns ads aio akode akonadi
     apache2 aqua_theme async banshee bash-completion bind blender
     blender-game boost c++ ccache cdr cgi cover css curl curlwrappers cxx
     dhcp dhcpcd drm-next dvd examples exceptions extensions extra
     extra-algorithms extraengine extrafilters extras ffmpeg firefox3 flash
     fortune fts3 gd gimp git github glib gnutls google google-gadgets gpg
     graphviz grub gstreamer hddtemp hdri html http i18n icu id3 id3tag java
     java6 jpeg2k kate kcal kdcraw kde kdevplatform kdm kdrive kerberos kexi
     keyboard kpoll lame ldap-sasl libsigsegv libssh2 linux-smp-stats
     lm_sensors logrotate mjpeg mmxext mng mono mozbranding mozdevelop
     mozembed mp3tunes mpe mpi mpi-threads mplayer musicbrainz mysql net
     netpbm network nsplugin nss numeric nvidia nvram offensive ogg123 ogm
     okular openexr openssl optimization optimized-qmake phonon php plasma
     player plugins posix postgres postproc postscript povray ps pth
     python-bindings python3 qt-dbus qt-webkit qt4 qtmultimedia raytracerx
     real regex rtc rtsp samba sasl scp secure-delete semantic
     semantic-desktop sensord server sftp sip smbclient smbkrb5passwd
     smbsharemodes sql sqlite ssh stream subversion swat swig symlink syslog
     taglib tcpdump tex tex4ht themes threads tools transcode utils uuid
     valgrind vdpau video_cards_nvidia vim vim-pager vim-syntax vlc wav webkit
     wireshark wma wmf xorgmodule youtube zeroconf zip -dso -hal -ipv6"

ACCEPT_KEYWORDS="~amd64"
ACCEPT_LICENSE="dlj-1.1"
PORTAGE_NICENESS=19
MAKEOPTS="-j2"
FEATURES="splitdebug nostrip"
LINGUAS="de en"
VIDEO_CARDS="nvidia"
INPUT_DEVICES="evdev keyboard mouse"

there's additionally the use flag "debug" set for glibc.

Is that helpful at all? I really need valgrind and must have this issue fixed in order to use it.

Cheers,
Stephan
Comment 40 Stephan Menzel 2010-06-15 15:20:35 UTC
PS: Could it be a ccache issue? I use ccache...
Comment 41 Zeev Tarantov 2010-06-15 17:24:26 UTC
Your glibc was compiled with debug symbols and with "nostrip", so valgrind should be happy, but, I've just noticed I'm using valgrind-9999 (from svn), so apparently 3.5.0 didn't work for me. I suggest trying that and hope what's in svn trunk compiles and works for you. My svn checkout is:

$ /usr/portage/distfiles/svn-src/valgrind/trunk
$ svn info
Path: .
URL: svn://svn.valgrind.org/valgrind/trunk
Repository Root: svn://svn.valgrind.org/valgrind
Repository UUID: a5019735-40e9-0310-863c-91ae7b9d1cf9
Revision: 11100
Node Kind: directory
Schedule: normal
Last Changed Author: bart
Last Changed Rev: 11100
Last Changed Date: 2010-04-02 13:27:35 +0300 (Fri, 02 Apr 2010)
Comment 42 Stephan Menzel 2010-06-16 06:57:17 UTC
Blast! I'm sitting behind a HTTP only firewall here and can't access svn repos. So I cannot try. Is there any place where I can get a snapshot with the patch via HTTP?
Comment 43 BlinkEye 2010-07-14 05:05:58 UTC
(In reply to comment #24)

That's interesting. As expected:

$ nm /usr/lib/debug/lib32/ld-2.11.2.so.debug | grep ' strlen'
00017fc0 t strlen

but strlen is missing in lib64:

$ nm /usr/lib/debug/lib64/ld-2.11.2.so.debug | grep ' strlen'
Comment 44 BlinkEye 2010-07-14 05:26:19 UTC
Request for re-opening this bug - it's not fixed in SVN (3.6.0) (see attachment)
Comment 45 BlinkEye 2010-07-14 05:27:39 UTC
/usr/local/bin/valgrind -v true                                                                                                                                                                                        
==14250== Memcheck, a memory error detector                                                                                                                                                                                                   
==14250== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.                                                                                                                                                                     
==14250== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info                                                                                                                                                               
==14250== Command: true                                                                                                                                                                                                                       
==14250==                                                                                                                                                                                                                                     
--14250-- Valgrind options:                                                                                                                                                                                                                   
--14250--    -v                                                                                                                                                                                                                               
--14250-- Contents of /proc/version:                                                                                                                                                                                                          
--14250--   Linux version 2.6.31-gentoo-r6 (root@quadux) (gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5) ) #8 SMP Fri Dec 18 14:00:52 CET 2009                                                                                             
--14250-- Arch and hwcaps: AMD64, amd64-sse3-cx16
--14250-- Page sizes: currently 4096, max supported 4096
--14250-- Valgrind library directory: /usr/local/lib/valgrind
--14250-- Reading syms from /bin/true (0x400000)
--14250--   Considering /usr/lib/debug/bin/true.debug ..
--14250--   .. CRC is valid
--14250-- Reading syms from /lib64/ld-2.11.2.so (0x4000000)
--14250--   Considering /usr/lib/debug/lib64/ld-2.11.2.so.debug ..
--14250--   .. CRC is valid

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-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.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.
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.
Comment 46 Stephan Menzel 2010-11-10 09:36:06 UTC
Well, are there any news on this one? I'd ove to have valgrind working again after more than a year now...

Stephan
Comment 47 Anthony Basile gentoo-dev 2010-11-10 12:08:08 UTC
There's still activity on this bug and it may not be resolved.  I'm going to reopen it.
Comment 48 Joerg Plate 2010-11-10 12:42:19 UTC
I emerged valgrind 3.6.0 and it didn't work. strace revealed the solution:

  cd /usr/lib64/debug
  ln -s lib64 lib

Now it works for me.
Comment 49 Casey Jones 2010-11-10 14:19:12 UTC
I remember checking this a couple of days ago with valgrind 3.5 and it wasn't working.  Emerged 3.6 yesterday and it's finally working without thousands of errors.
Comment 50 Stephan Menzel 2010-11-12 13:00:00 UTC
sadly I can not confirm this works now. valgrind 3.6 just came in on upstream and the bug still occurs.

I also tried the link trick Joerg mentioned. It's probably wrong though since the link points to nothing here.

I have "nostrip" and not "splitdebug".

Is there anything else one can try?
Comment 51 Anthony Basile gentoo-dev 2010-11-12 13:10:33 UTC
(In reply to comment #50)
> sadly I can not confirm this works now. valgrind 3.6 just came in on upstream
> and the bug still occurs.
> 
> I also tried the link trick Joerg mentioned. It's probably wrong though since
> the link points to nothing here.
> 
> I have "nostrip" and not "splitdebug".
> 
> Is there anything else one can try?
> 

Can you post your emerge --info.  I know there's an emerge info above, but its on an old 2008.0 profile.  I'm going to build a vm which is a close as possible to reproduce this bug and nail it.
Comment 52 Stephan Menzel 2010-11-12 13:34:29 UTC
Created attachment 254083 [details]
emerge --info

Sure, no problem. Here it is.
Let me know if I can provide anything else.

Cheers,
Stephan
Comment 53 Anthony Basile gentoo-dev 2010-11-12 21:38:48 UTC
Created attachment 254133 [details]
My emerge info

I was not able to hit the bug, ie. valgrind worked fine for me on ls, ldd and some other random tests.  Comparing my emerge --info with the the previous comment, the only significant differences I see is glibc.  I have 2.11.2-r3 and above we have 2.12.1-r3.  There are some other difference but I'm not sure they are significant.

Maybe we should compare make.conf's.  I have:

CFLAGS="-O2 -pipe -ggdb"
CXXFLAGS="${CFLAGS}"
CHOST="x86_64-pc-linux-gnu"
USE="mmx sse sse2"
FEATURES="nostrip"
Comment 54 Nikos Chantziaras 2010-11-12 22:39:41 UTC
I also have no problems with valgrind anymore. I'm on glibc 2.11.2-r3.  I never updated to 2.12 simply because portage seems to make it impossible to downgrade again unless I start hacking it. So I tend to wait many months before updating glibc on my system.
Comment 55 Anthony Basile gentoo-dev 2010-11-13 02:05:14 UTC
Okay I think I know what's going on here.  To confirm my suspicion, I upgraded from glibc 2.11.2-r3 to 2.12.1-r3 by *just* emerge =sys-lib/glibc-2.12.1-r3 and leaving the rest of my system untouched.  Immediately after, I tried valgrind which had worked under 2.11.2-r3 and it failed --- see the failure below.  I then emerge -e world and it worked.

Aside: upgrading glibc should not be taken lightly.  Whenever I change any part of my toolchain, I emerge -e world.

Can someone repeat the above and confirm?




valgrind portage # valgrind /bin/ls
==30229== Memcheck, a memory error detector
==30229== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==30229== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==30229== Command: /bin/ls
==30229== 
==30229== Conditional jump or move depends on uninitialised value(s)
==30229==    at 0x40163F6: index (strchr.S:56)
==30229==    by 0x4007264: expand_dynamic_string_token (dl-load.c:320)
==30229==    by 0x400766F: _dl_map_object (dl-load.c:2184)
==30229==    by 0x400198D: map_doit (rtld.c:629)
==30229==    by 0x400D8A5: _dl_catch_error (dl-error.c:178)
==30229==    by 0x40018A6: do_preload (rtld.c:813)
==30229==    by 0x40044A7: dl_main (rtld.c:1691)
==30229==    by 0x4014907: _dl_sysdep_start (dl-sysdep.c:244)
==30229==    by 0x40014D2: _dl_start (rtld.c:334)
==30229==    by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so)
==30229== 
==30229== Conditional jump or move depends on uninitialised value(s)
==30229==    at 0x40163FB: index (strchr.S:59)
==30229==    by 0x4007264: expand_dynamic_string_token (dl-load.c:320)
==30229==    by 0x400766F: _dl_map_object (dl-load.c:2184)
==30229==    by 0x400198D: map_doit (rtld.c:629)
==30229==    by 0x400D8A5: _dl_catch_error (dl-error.c:178)
==30229==    by 0x40018A6: do_preload (rtld.c:813)
==30229==    by 0x40044A7: dl_main (rtld.c:1691)
==30229==    by 0x4014907: _dl_sysdep_start (dl-sysdep.c:244)
==30229==    by 0x40014D2: _dl_start (rtld.c:334)
==30229==    by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so)
==30229== 
bin  package.keywords  package.unmask  postsync.d  savedconfig
==30229== 
==30229== HEAP SUMMARY:
==30229==     in use at exit: 20,171 bytes in 11 blocks
==30229==   total heap usage: 16 allocs, 5 frees, 53,057 bytes allocated
==30229== 
==30229== LEAK SUMMARY:
==30229==    definitely lost: 0 bytes in 0 blocks
==30229==    indirectly lost: 0 bytes in 0 blocks
==30229==      possibly lost: 0 bytes in 0 blocks
==30229==    still reachable: 20,171 bytes in 11 blocks
==30229==         suppressed: 0 bytes in 0 blocks
==30229== Rerun with --leak-check=full to see details of leaked memory
==30229== 
==30229== For counts of detected and suppressed errors, rerun with: -v
==30229== Use --track-origins=yes to see where uninitialised values come from
==30229== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
Comment 56 Stephan Menzel 2010-11-15 08:15:42 UTC
Hi,

I'd like to reply to some of the last comments. Yes, I do have glibc 2.12 but I really don't think this is so closely related as it may seem.
a)
I've been having this problem for at least a year now and during that time I've had a fair number of glibc revisions. I always do the upgrade when it comes in on upstream and rarely had any kind of problem.

b)
I maintain 2 systems with almost completely the same setup, make.conf and all but one is x86 and one is AMD64. They have the same glibc revision and build flags. The problem only occurs on the AMD64 one. Sadly, this is the one at work where I need valgrind :-(

I believe the reason is the debug info for glibc can either not be found or when they can, don't contain the strlen symbol because of strlen being inlined away by or some such optimization magic.

However, I can do a downgrade to prove my point here.

Comment 57 Stephan Menzel 2010-11-15 08:22:18 UTC
(In reply to comment #56)
> 
> However, I can do a downgrade to prove my point here.
> 

Correction: No, I can not. I just learned downgrading glibc is not supported. Sorry. But consider glibc 2.12 wasn't out a year ago when this bug was filed.

S.
Comment 58 Stephan Menzel 2010-11-15 08:35:06 UTC
(In reply to comment #55)
> leaving the rest of my system untouched.  Immediately after, I tried valgrind
> which had worked under 2.11.2-r3 and it failed --- see the failure below.  I
> then emerge -e world and it worked.

Anthony, to respond to this one, the output you post is a relatively normal valgrind output. The tool actually runs all the way to the end to present you the Heap summary. So this is not an error. At least not one related to the one this bug is about. So your test just proved you don't have the problem with your make.conf and toolset.
Since you have just set this up, maybe it's got something to do with the age of the system. Maybe some glibc upgrade a long time ago left somethig  behind that causes this so a freshly setup system won't have it? Can anyone tell me how I can scan the system for possible debris of older upgrades? Is there a gentoo tool for that?

S.
Comment 59 Anthony Basile gentoo-dev 2010-11-15 10:34:41 UTC
(In reply to comment #58)
> The tool actually runs all the way to the end to present you
> the Heap summary. So this is not an error. At least not one related to the one
> this bug is about. So your test just proved you don't have the problem with
> your make.conf and toolset.

Yep, the original was strictly on strlen.

> Since you have just set this up, maybe it's got something to do with the age of
> the system. Maybe some glibc upgrade a long time ago left somethig  behind that
> causes this so a freshly setup system won't have it? Can anyone tell me how I
> can scan the system for possible debris of older upgrades? Is there a gentoo
> tool for that?

Upgrade paths make a difference and I've seen toolchains break as a result.  I wish there were a tool to find such problems.  The best I can think of is something like epm where you can do epm -qf to see if a file belongs to a package or not.  However, this is like searching for a needle in a haystack.

I don't know how to proceed with this one.  If you can hit it using a fresh build and post step by step how to get to the error it would make life a lot easier --- I understand the difficulty in this :(

Comment 60 Stephan Menzel 2010-11-15 14:27:38 UTC
Well, frankly a fresh install is for me just not in the cards right now. What I just did was trying to find such orphans. First I looked for *.la files and deleted all the orphaned ones. Just a few. Then I did the same search for left behind *.so files as such:

qfile -o `find /lib/ /usr/lib/ /lib32 /lib64 /usr/local/lib/ /usr/x86_64-pc-linux-gnu/lib/ -name \*.so\*`

Surprisingly there were quite a few. I have no idea though whether it would be wise to delete them. This is the output I got:

/lib/libdevmapper-event-lvm2mirror.so.2.02
/lib/libdevmapper-event-lvm2snapshot.so.2.02
/lib/libgcc_s.so.1
/lib/modules/2.6.35-gentoo-r10/modules.softdep
/lib/modules/2.6.36-gentoo/modules.softdep
/usr/lib/libboost_python-mt.so
/usr/lib/libboost_python.so
/usr/lib/libboost_prg_exec_monitor-mt.so
/usr/lib/libboost_wserialization.so
/usr/lib/libpgtypes.so
/usr/lib/libnvidia-cfg.so.1
/usr/lib/libdb_java.so
/usr/lib/libnvcuvid.so.1
/usr/lib/libboost_thread-mt.so
/usr/lib/libtalloc.so.2
/usr/lib/libboost_math_c99l.so
/usr/lib/libboost_iostreams-mt.so
/usr/lib/libdb_cxx.so
/usr/lib/libblas.so
/usr/lib/libboost_math_tr1f-mt.so
/usr/lib/libecpg.so
/usr/lib/libblas.so.0
/usr/lib/libboost_math_tr1l-mt.so
/usr/lib/libboost_system-mt.so
/usr/lib/libboost_math_c99l-mt.so
/usr/lib/libboost_prg_exec_monitor.so
/usr/lib/libcblas.so
/usr/lib/libboost_graph_parallel-mt.so
/usr/lib/nsbrowser/plugins/npwrapper.nppdf.so
/usr/lib/nsbrowser/plugins/javaplugin.so
/usr/lib/libboost_mpi-mt.so
/usr/lib/libecpg_compat.so
/usr/lib/libboost_regex.so
/usr/lib/libboost_signals-mt.so
/usr/lib/libboost_iostreams.so
/usr/lib/libboost_math_tr1.so
/usr/lib/libboost_serialization.so
/usr/lib/libboost_date_time.so
/usr/lib/libcblas.so.0
/usr/lib/libboost_system.so
/usr/lib/libboost_mpi_python-mt.so
/usr/lib/libboost_random-mt.so
/usr/lib/libGL.so
/usr/lib/libboost_wave-mt.so
/usr/lib/libboost_unit_test_framework-mt.so
/usr/lib/libGLcore.so
/usr/lib/libboost_random.so
/usr/lib/libboost_filesystem.so
/usr/lib/libboost_math_c99f.so
/usr/lib/libboost_graph-mt.so
/usr/lib/libboost_math_tr1-mt.so
/usr/lib/libboost_regex-mt.so
/usr/lib/libdb.so
/usr/lib/libboost_filesystem-mt.so
/usr/lib/xorg/modules/extensions/libglx.so
/usr/lib/libboost_wave.so
/usr/lib/libpq.so
/usr/lib/libboost_signals.so
/usr/lib/python2.6/site-packages/mpi.so
/usr/lib/libboost_math_tr1l.so
/usr/lib/libboost_math_c99-mt.so
/usr/lib/libboost_mpi.so
/usr/lib/libboost_math_c99f-mt.so
/usr/lib/libboost_math_c99.so
/usr/lib/libboost_program_options.so
/usr/lib/libboost_unit_test_framework.so
/usr/lib/libboost_program_options-mt.so
/usr/lib/libboost_math_tr1f.so
/usr/lib/libboost_serialization-mt.so
/usr/lib/libboost_graph.so
/usr/lib/libboost_date_time-mt.so
/usr/lib/libXvMCNVIDIA_dynamic.so.1
/usr/lib/libboost_thread.so
/usr/lib/libboost_wserialization-mt.so
/lib32/libgcc_s.so.1
/lib64/libdevmapper-event-lvm2mirror.so.2.02
/lib64/libdevmapper-event-lvm2snapshot.so.2.02
/lib64/libgcc_s.so.1
/lib64/modules/2.6.35-gentoo-r10/modules.softdep
/lib64/modules/2.6.36-gentoo/modules.softdep
/usr/local/lib/libcurlpp.so
/usr/local/lib/libglog.so
/usr/local/lib/libutilspp.so
/usr/local/lib/libcurlpp.so.0
/usr/local/lib/libglog.so.0
/usr/local/lib/libgtest.so.0.0.0
/usr/local/lib/libgtest_main.so
/usr/local/lib/libcurlpp.so.0.0.2
/usr/local/lib/libgtest.so
/usr/local/lib/libjrtp.so
/usr/local/lib/libjrtp-3.8.0.so
/usr/local/lib/libeqserver.so
/usr/local/lib/libeq.so
/usr/local/lib/libgtest_main.so.0
/usr/local/lib/libutilspp.so.0
/usr/local/lib/libgtest_main.so.0.0.0
/usr/local/lib/libglog.so.0.0.0
/usr/local/lib/libutilspp.so.0.0.0
/usr/local/lib/libgtest.so.0
/usr/x86_64-pc-linux-gnu/lib/libopcodes-2.20.1.20100303.so
/usr/x86_64-pc-linux-gnu/lib/libbfd.so
/usr/x86_64-pc-linux-gnu/lib/libbfd-2.20.1.20100303.so
/usr/x86_64-pc-linux-gnu/lib/libopcodes.so

I really didn't expect that many.
The way I understand gentoo it doesn't know about these files so in a fresh install they wouldn't be there but the system would work, right? So I could delete them. But would that do any good about this? If there is no chance it could solve the issue I#d rather leave them alone because there appears to be some risk involved.

What's your suggestion?

Cheers,
Stephan
Comment 61 Oleg 2010-12-29 11:16:42 UTC
When trying to emerge glibc-2.11.2-r3 with USE="debug" and FEATURES="splitdebug" got next installation error:

 * >>> SetUID: [chmod go-r] /usr/lib32/misc/glibc/pt_chown ...                                                                                      [ ok ]
!!! FAILED prerm: 2816
 * The ebuild phase 'postrm' has exited unexpectedly. This type of behavior
 * is known to be triggered by things such as failed variable assignments
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before
 * exiting, bash should have displayed an error message above. If bash did
 * not produce an error message above, it's possible that the ebuild has
 * called `exit` when it should have called `die` instead. This behavior
 * may also be triggered by a corrupt bash binary or a hardware problem
 * such as memory or cpu malfunction. If the problem is not reproducible or
 * it appears to occur randomly, then it is likely to be triggered by a
 * hardware problem. If you suspect a hardware problem then you should try
 * some basic hardware diagnostics such as memtest. Please do not report
 * this as a bug unless it is consistently reproducible and you are sure
 * that your bash binary and hardware are functioning properly.
Sandboxed process killed by signal: Segmentation fault
 * The ebuild phase 'die_hooks' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.
!!! FAILED postrm: 1
 * The 'postrm' phase of the 'sys-libs/glibc-2.11.2-r3' package has failed
 * with exit value 1.
 * 
 * The problem occurred while executing the ebuild file named
 * 'glibc-2.11.2-r3.ebuild' located in the '/var/db/pkg/sys-
 * libs/glibc-2.11.2-r3' directory. If necessary, manually remove the
 * environment.bz2 file and/or the ebuild file located in that directory.
 * 
 * Removal of the environment.bz2 file is preferred since it may allow the
 * removal phases to execute successfully. The ebuild will be sourced and
 * the eclasses from the current portage tree will be used when necessary.
 * Removal of the ebuild file will cause the pkg_prerm() and pkg_postrm()
 * removal phases to be skipped entirely.
 * The ebuild phase 'postinst' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.
Sandboxed process killed by signal: Segmentation fault
 * The ebuild phase 'die_hooks' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.
!!! FAILED postinst: 1
Sandboxed process killed by signal: Segmentation fault
 * The ebuild phase 'success_hooks' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.
Sandboxed process killed by signal: Segmentation fault
 * The ebuild phase 'die_hooks' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.

 * Messages for package sys-libs/glibc-2.11.2-r3:

 * The ebuild phase 'postrm' has exited unexpectedly. This type of behavior
 * is known to be triggered by things such as failed variable assignments
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before
 * exiting, bash should have displayed an error message above. If bash did
 * not produce an error message above, it's possible that the ebuild has
 * called `exit` when it should have called `die` instead. This behavior
 * may also be triggered by a corrupt bash binary or a hardware problem
 * such as memory or cpu malfunction. If the problem is not reproducible or
 * it appears to occur randomly, then it is likely to be triggered by a
 * hardware problem. If you suspect a hardware problem then you should try
 * some basic hardware diagnostics such as memtest. Please do not report
 * this as a bug unless it is consistently reproducible and you are sure
 * that your bash binary and hardware are functioning properly.
 * The 'postrm' phase of the 'sys-libs/glibc-2.11.2-r3' package has failed
 * with exit value 1.
 * 
 * The problem occurred while executing the ebuild file named
 * 'glibc-2.11.2-r3.ebuild' located in the '/var/db/pkg/sys-
 * libs/glibc-2.11.2-r3' directory. If necessary, manually remove the
 * environment.bz2 file and/or the ebuild file located in that directory.
 * 
 * Removal of the environment.bz2 file is preferred since it may allow the
 * removal phases to execute successfully. The ebuild will be sourced and
 * the eclasses from the current portage tree will be used when necessary.
 * Removal of the ebuild file will cause the pkg_prerm() and pkg_postrm()
 * removal phases to be skipped entirely.

 * Messages for package sys-libs/glibc-2.11.2-r3:

 * The ebuild phase 'postinst' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.
Comment 62 Oleg 2010-12-29 11:21:38 UTC
Created attachment 258334 [details]
My emerge --info

Also I get in stderr:
"!!! No gcc found. You probably need to 'source /etc/profile'
!!! to update the environment of this terminal and possibly
!!! other terminals also."
And I get segfaults in catch signals and cann't run gdb.
Comment 63 Oleg 2010-12-29 11:31:19 UTC
Also,I cann't reemere without debug:

# emerge -1 glibc

 * IMPORTANT: 6 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) sys-libs/glibc-2.11.2-r3
Sandboxed process killed by signal: Segmentation fault
 * The ebuild phase 'die_hooks' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.

>>> Failed to emerge sys-libs/glibc-2.11.2-r3

 * Messages for package sys-libs/glibc-2.11.2-r3:


 * IMPORTANT: 6 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.
Comment 64 Stephan Menzel 2010-12-30 18:40:41 UTC
Oleg,

are you sure this has got anything to do with this bug? If so, what makes you think so?

Cheers,
Stephan
Comment 65 Oleg 2011-01-04 16:24:40 UTC
Can I add debug info into glibc by other methods?
Comment 66 Nikos Chantziaras 2011-01-04 16:37:26 UTC
(In reply to comment #65)
> Can I add debug info into glibc by other methods?

No, because the *.so files themselves need to contain links to the debug information files.

Do not put "debug" in USE. Never do that! All you need is "-g" in CFLAGS and "splitdebug" in FEATURES.

Putting "debug" in USE does much more than just generate debug info; it enabled extra debugging paths (assertions and extra checks) in the code and is intended to be used by developers of those packages.

Also, your CFLAGS look silly to me. Use something line "-pipe -g -O2 -march=generic".
Comment 67 Nikos Chantziaras 2011-01-04 16:40:35 UTC
(In reply to comment #66)
> Also, your CFLAGS look silly to me. Use something line "-pipe -g -O2
> -march=generic".

Er, oops, I meant "-march=native" of course, not "generic".
Comment 68 Krists Krilovs 2011-04-20 23:42:14 UTC
Is it possible that using older gcc as default compiler causes this problem? I have two amd64 systems which are very similar. Both use glibc-2.12.1-r3. But valgrind reports the error only on the system which has gcc-4.4.2 as system compiler. I did emerge -e world and glibc is emerged with FEATURES="splitdebug" and valgrind still doesn't work.
The other system with gcc-4.5.2 as system compiler doesn't have any problems with valgrind. Info from the system where valgrind doesn't work:

$ gcc-config -l
 [1] x86_64-pc-linux-gnu-4.2.4
 [2] x86_64-pc-linux-gnu-4.3.5
 [3] x86_64-pc-linux-gnu-4.4.2 *
 [4] x86_64-pc-linux-gnu-4.5.2
$ valgrind -v ldd
==4747== Memcheck, a memory error detector
==4747== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==4747== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==4747== Command: /usr/bin/ldd
==4747== 
--4747-- Valgrind options:
--4747--    -v
--4747-- Contents of /proc/version:
--4747--   Linux version 2.6.38-gentoo-r1 (root@d630) (gcc version 4.4.2 (Gentoo 4.4.2 p1.0) ) #1 SMP PREEMPT Mon Apr 18 10:58:47 PDT 2011
--4747-- Arch and hwcaps: AMD64, amd64-sse3-cx16
--4747-- Page sizes: currently 4096, max supported 4096
--4747-- Valgrind library directory: /usr/lib64/valgrind
--4747-- Reading syms from /bin/bash (0x400000)
--4747--    object doesn't have a symbol table
--4747-- Reading syms from /lib64/ld-2.12.1.so (0x4000000)
--4747--   Considering /usr/lib/debug/lib64/ld-2.12.1.so.debug ..
--4747--   .. CRC is valid

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:  Cannot continue -- exiting now.  Sorry.
$  nm /usr/lib/debug/lib64/ld-2.12.1.so.debug | grep ' strlen$'
$  nm /usr/lib/debug/lib32/ld-2.12.1.so.debug | grep ' strlen$'
$ nm /usr/lib/debug/lib64/libc-2.12.1.so.debug | grep ' strlen$'
0000000000078960 i strlen
$ nm /usr/lib/debug/lib64/libc-2.12.1.so.debug | grep ' malloc$'
0000000000073c79 T malloc
$ file /usr/lib*
/usr/lib:     symbolic link to `lib64'
/usr/lib32:   directory
/usr/lib64:   directory
/usr/libexec: directory
Comment 69 Anthony Basile gentoo-dev 2011-04-21 11:36:06 UTC
(In reply to comment #68)
> Is it possible that using older gcc as default compiler causes this problem? I
> have two amd64 systems which are very similar. Both use glibc-2.12.1-r3. But
> valgrind reports the error only on the system which has gcc-4.4.2 as system
> compiler. I did emerge -e world and glibc is emerged with FEATURES="splitdebug"
> and valgrind still doesn't work.
> The other system with gcc-4.5.2 as system compiler doesn't have any problems
> with valgrind. Info from the system where valgrind doesn't work:
> 

I have not been able to get a handle on this bug because I was never able to reproduce it.  I've used valgrind with both compilers, no problem.  My suspicion is that your compiler is broken but that's just a guess because you were able to emerge -e world with it.
Comment 70 Kamil Dudka 2011-05-29 11:31:01 UTC
(In reply to comment #0)
> 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-x86-64.so.2
> valgrind:  was not found whilst processing
> valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2

I was getting exactly this ^^^ even for 'valgrind /bin/true' after upgrade to glibc-2.12.2 with gcc-4.5.2 and -march=nocona in CFLAGS.  I temporarily removed -march=nocona from CFLAGS, rebuilt glibc and the problem vanished.
Comment 71 Nikos Chantziaras 2011-05-29 13:09:04 UTC
You should replace -march=nocona with -march=native anyway.
Comment 72 Kamil Dudka 2011-05-29 13:21:48 UTC
(In reply to comment #71)
> You should replace -march=nocona with -march=native anyway.

Is -march=native compatible with distcc?  If it inherited the flags from the distcc host, which defaults to -march=core2, it would end up with a broken glibc installation on my laptop.

Anyway, I suspect that -march=nocona is equivalent to -march=native on my laptop.  Why do you think that -march=native is going to solve the problem in general?
Comment 73 Nikos Chantziaras 2011-05-29 13:33:16 UTC
(In reply to comment #72)
> Anyway, I suspect that -march=nocona is equivalent to -march=native on my
> laptop.  Why do you think that -march=native is going to solve the problem in
> general?

Because traditionally, "nocona" was used due to GCC not having a flag for "core2" and "atom" in earlier versions. I assumed you were one of those cases, simply because there are so many core2 and atom users who still use "nocona" ;-)  If you really have a Pentium4 (with 64-bit extensions) laptop though, then yes, "nocona" is correct.

No idea about distcc.
Comment 74 Kamil Dudka 2011-05-29 13:50:11 UTC
It does, however, not explain why the symbol strlen is missing in /lib64/ld-2.12.2.so when compiled with -march=nocona.  Is it a glibc bug?  A gcc bug?  valgrind's wrong assumption about availability of that symbol?  A user error?

I would still like to get back the optimized glibc as soon as this issue is resolved.  Here are the involved ebuilds:

sys-devel/gcc-4.5.2
sys-libs/glibc-2.12.2
dev-util/valgrind-3.6.1
Comment 75 Kamil Dudka 2011-05-29 16:41:47 UTC
The problem is that gcc optimizes out all calls of strlen() when building ld-2.12.2.so and the symbol is then not available from outside, which badly surprises valgrind.  Forwarded upstream:

https://bugs.kde.org/show_bug.cgi?id=190429#c17
Comment 76 Krists Krilovs 2011-09-26 19:19:24 UTC
Thank you Kamil. I confirm that changing -march=nocona to -march=core2 in make.conf and reemerging glibc solved the issue.
Comment 77 Stephan Menzel 2012-02-25 09:33:57 UTC
I just gave it another try here and it doesn't occur anymore. Don't know why or since when exactly but I consider it fixed.

Stephan
Comment 78 Ilia Pozhilov 2012-05-11 07:11:43 UTC
Created attachment 311403 [details]
My emerge --info
Comment 79 Ilia Pozhilov 2012-05-11 07:14:38 UTC
Still there for me, attached emerge --info
valgrind-3.6.1-r3
note -march=native in my make.conf
Comment 80 Guenther Brunthaler 2012-05-11 11:51:13 UTC
I just want to add a fact for the casual reader who looks into this bug report because *running* valgrind (rather than building it) spews out a long of messages regarding libc internals rather than problems in the actual application.

The important thing to note here is that valgrind creates an exclusion list for such libc-internal warnings when it is emerged.

Therefore, every time glibc gets emerged, valgrind should be re-emerged after that too.

Then valgrind will rebuild its exclusion list, and glibc-internal problems will no longer be displayed.
Comment 81 Kamil Dudka 2012-05-11 12:05:05 UTC
(In reply to comment #80)
> The important thing to note here is that valgrind creates an exclusion list
> for such libc-internal warnings when it is emerged.

That's certainly an important thing, but not the only thing discussed here.

> Therefore, every time glibc gets emerged, valgrind should be re-emerged
> after that too.
> 
> Then valgrind will rebuild its exclusion list, and glibc-internal problems
> will no longer be displayed.

Still, if /lib/ld-2.??.?.so does not expose the strlen symbol, valgrind fails to start.  Rebuild of valgrind could hardly solve this issue, since it is glibc that needs to be rebuilt to make the symbol available.
Comment 82 Anthony Basile gentoo-dev 2012-09-14 11:30:40 UTC

*** This bug has been marked as a duplicate of bug 390323 ***