Valgrind not working with glibc-2.36-2

Running valgrind returns this output

==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?

Same here with glibc-2.36-3, debuginfod 0.187-2, valgrind 3.19.0-5.

I really want valgrind to work. None of the given solution work.
Does anyone have a solution? Struggling for a month now already.

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

are there any mirrors of the debuginfod server by arch that are older versions? Maybe I could download the server through waybackintime machine?

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.

hmm, they updated glibc today to the latest version and it appears that valgrind is still not working for me

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.

@Yochanan

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.

Thanks for the clarification. valgrind works now.

But still, as Manjaro stable will always be behind Arch, we will run into this problem over and over again.
A real solution is needed.

Indeed, the real solution would be a Manjaro debuginfod server.

1 Like

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?

Many thanks in advance.

valgrind will only work if your glibc version matches the one in the Arch Linux repositories. It is 2.36-6 as of writing.

1 Like

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… :frowning_face:

3 Likes

Unfortunately after every update i have this issue , Do the developers take this issue into account?

2 Likes

I found a solution that worked for me using stable branch.
Instead of using DEBUGINFOD_URLS=https://debuginfod.archlinux.org/
I used DEBUGINFOD_URLS=https://debuginfod.elfutils.org/
I assume that one of the servers in elfutils have older version of glibc which match the version used in manjaro stable.

You can actually specify multiple addresses in DEBUGINFOD_URLS, e.g.

export DEBUGINFOD_URLS="https://debuginfod.archlinux.org https://debuginfod.elfutils.org"

In any case, debuginfod.elfutils.org federates with other debuginfod servers, including that of Arch Linux, and I imagine they keep the files around for longer.