Valgrind missing debuginfo (since August 22)

Support Software & Applications
1

Hello. Whenever I use valgrind, I get this (on 3 different PCs):

==6657== Memcheck, a memory error detector
==6657== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==6657== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==6657== Command: ./src/Tests/save-osc test-all
==6657== 

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.

My system info:

$ pacman -Q glibc valgrind
glibc 2.37-2
valgrind 3.20.0-1

With gdb, debuginfod works fine.

What I have found so far:

  • Cannot use valgrind - They suggest downgrading glibc, but claim that it was fixed in glibc 2.35-6. I’m not sure if downgrading is really a good idea, if the new version should already support it. Even if I downgrade, doesn’t using old software mean that I miss current security updates, which means a security risk?
  • Valgrind problem after glibc update - They suggest exporting DEBUGINFOD_URLS="https://debuginfod.archlinux.org", but that does not help in my case.
  • Unable to use valgrind - Mostly no solution, some people have solved it with upgrading, but their glibc was older than my current glibc.

Can anyone please help? Thanks on advance.

2

You need to use the Manjaro unstable branch if you want to use valgrind without problems. Even in the testing branch are time-windows where valgrind will not work. At the moment testing should work.

Valgrind will stop working every time the glibc version in the stable branch differs form the version in the unstable branch. And it is not only the glibc version it is also the package version (the number after the dash).

At the moment glibc is in stable at 2.37-2 and in testing and unstable at 2.37-3.

If you want to stay in stable, you need to wait for the next update. But in some case, the version in unstable might have changed already. So Valgrind and the stable branch are a no go.

3

Doesn’t using unstable glibc not only mean a security risk, but also a maintenance risk? It sounds like this library could even cause issues with starting up my PC?

If there’s no alternative, what are the commands to only keep glibc being pulled from the unstable branch?

4

Security risk, no why? Manjaro Unstable is Arch Stable. Maintenance risk, yes, it is called unstable for a reason.

No.

This is called a partial update. It is not supported and will result in problems. Do not do this! If you want a newer version, switch branch and update everything. There are no shortcuts.

1 Like
5

OK, thanks a lot for explaining. If there will be no alternative solution soon, I will just take yours and mark your answer as solution. Though, it all sounds like it’s unlikely that there will be another solution. :smile:

6

There isn’t (short of going to Ubuntu or similar), I’ll just add:

You don’t have to be rolling-rolling and jump on every update (that’s kind of a point and good for community but you don’t have to and I often don’t), you can be very lazy rolling, find your ‘stable update’ whether you’re on unstable or testing and keep it if you’re busy (if you don’t have to install anything new you’ll be fine). Watch the chat and when issues are resolved (if any) do another update, and do that in a loop. If you’re extra busy, drop to testing (when versions are the same) and that’ll give you some extra time.
Also, unstable or testing isn’t scary at all :slight_smile: - stable branch for me (personal view) can be more unstable at times. Keep timeshift backups and if you’re valgrind user you should be fine.

7

Related: https://forum.manjaro.org/t/any-fix-to-find-debug-symbols-for-stable-packages