Bug 1661510

Sorry, reopening this bug because after this fix ld-2.29.9000.so from glibc-2.29.9000-12.fc31 is missing .symtab.
Don't know how that happened. It might be that the rpm find-debuginfo.sh fix, for -g-libs is incorrect.

Yep, it broke valgrind

sh-5.0$ rpm -q glibc valgrind
glibc-2.29.9000-12.fc31.x86_64
valgrind-3.15.0-0.2.RC1.fc31.x86_64

sh-5.0$ valgrind /bin/ls
==15677== Memcheck, a memory error detector
==15677== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==15677== Using Valgrind-3.15.0.RC1 and LibVEX; rerun with -h for copyright info
==15677== Command: /bin/ls
==15677== 

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.  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:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.

(In reply to Lukas Slebodnik from comment #2)
> Yep, it broke valgrind
> 
> sh-5.0$ rpm -q glibc valgrind
> glibc-2.29.9000-12.fc31.x86_64
> valgrind-3.15.0-0.2.RC1.fc31.x86_64

That means that the valgrind sanity check inside the glibc.spec didn't catch this.

%if %{with valgrind}
elf/ld.so --library-path .:elf:nptl:dlfcn \
        /usr/bin/valgrind --error-exitcode=1 \
        elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/true
%endif

Which should in theory have caught this. But maybe invoking ld.so directly doesn't trigger the valgrind interceptors, or this ld.so isn't stripped (yet?).

(In reply to Mark Wielaard from comment #3)
> (In reply to Lukas Slebodnik from comment #2)
> > Yep, it broke valgrind
> > 
> > sh-5.0$ rpm -q glibc valgrind
> > glibc-2.29.9000-12.fc31.x86_64
> > valgrind-3.15.0-0.2.RC1.fc31.x86_64
> 
> That means that the valgrind sanity check inside the glibc.spec didn't catch
> this.
> 
> %if %{with valgrind}
> elf/ld.so --library-path .:elf:nptl:dlfcn \
>         /usr/bin/valgrind --error-exitcode=1 \
>         elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/true
> %endif
> 
> Which should in theory have caught this. But maybe invoking ld.so directly
> doesn't trigger the valgrind interceptors, or this ld.so isn't stripped
> (yet?).

I thought so too, but then I realized that we run on the built binary, not on the installed one that goes into the RPM files.  Since we invoke find-debuginfo.sh ourselves, we should have access to the actual binaries and could use those.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

We need to port rpm's find-debuginfo.sh to the new eu-elfclassify tool, and then --g-libs will work as expected for glibc. Until that has happned, this bug is blocked.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Patch posted: <https://lists.fedoraproject.org/archives/list/glibc@lists.fedoraproject.org/message/7OMASUGX2Q6ODQAOC5W23BNGPBM2VGDD/>

FEDORA-2021-2ba993d6c5 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-2ba993d6c5

FEDORA-2021-2ba993d6c5 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-2ba993d6c5`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-2ba993d6c5

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-2ba993d6c5 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Fixed in Fedora 33 in version glibc-2.32-6.fc33.