==43271== Memcheck, a memory error detector
==43271== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==43271== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==43271== Command: ls
==43271==
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.
I have tried the solutions suggested in this thread, including downgrading glibc, setting the DEBUGINFOD_URLS environment variable, and running "/etc/profile.d/debuginfod.sh" to no avail. Has anyone else been having this issue and found a solution yet?
The problem seems to be that the debuginfo url is pointing to a server hosted by Archlinux.
And since Archlinux is most of the time a bit ahead of Manjaro, the glibc package there is currently at glibc-2.36-4 which differs significantly from what we currently have in Manjaros stable branch: glibc-2.36-3
Unless Manjaro team offers their own debuginfo server instance serving the correct matching package versions, we will run again and again into this issue. Not sure if the Manjaro core team is aware of this gap already? @philm
I am not aware of any other instance.
What I read from other threads reporting the same issue is to update the glibc package to the newer version. It can be found in the unstable or testing branch of the Manjaro repos.
But to be honest I do not want to break anything by doing this. I need the system to do my work…
Actually, the valgrind package as it is at the moment is completely unusable.
glibc 2.36-4.0 in the Manjaro repositories is not the same as the one that Arch Linux has, so debuginfo is not available for it from the Arch Linux debuginfod server. At first glance, it’s not clear to me why they are different given that Arch Linux also applies the “reenable DT_HASH” patch.
There were Calamares locale issues with new installs with 2.36-4.
Commits that were only in trunk were applied as Arch hadn’t pushed them with a new pkgrel yet. 2.36-4.0 is effectively 2.36-5 (currently in Arch Testing now in Arch Stable / Manjaro unstable) without the rebuild with pacman 6.0.2.
Excuse me, would you be so kind and explain what you did to make valgrind work again?
I’m currently on glibc-2.36-4.0 and also have installed debuginfod-0.187-2. Do I need to install a newer version of glibc from the unstable repo?
Thanks @pobrn! valgrind works now.
In summary: As mentioned above, this will continue to happen if the glibc version of the Manjaro stable repo is older than that of Arch Linux. That means if this problem occurs again, one has to check if one has installed the same version of glibc as the one available in the Arch repo. Then one can upgrade the glibc version with the command: sudo DOWNGRADE_FROM_ALA=1 downgrade glibc (Not sure if this is the right way to do it)
Well, a few months later, and the problem resurfaced again. Arch seems to be at glibc 2.37-2, Manjaro at 2.36-7, and valgrid is useless/broken again…