+++ This bug was initially created as a clone of Bug #1661508 +++ The fix for bug 1186563 has the side effect that binaries are no longer stripped because glibc.spec uses the -g option. This adds a measurable overhead to the packages.
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.