Constant trouble with valgrind

bztarch · 2025-08-08 07:20:32

Hi All,

Please do something with valgrind and gdb with this shitty debuginfod because it keeps breaking EVERY time I upgrade my Arch. This is NOT a newbie issue, and NOT a technical issue, rather a matter of a missing essential base package.

Problem:
Because essential libraries in the base repo are missing debug info, so valgrind and gdb is missing an essential dependency, and they crash and doesn't work. (You can turn this off in gdb, but valgrind really does not even start, so this is a FATAL error)

Suggestion:
The one and only permanent solution to this constant problem is to provide a libc-dbg package with the base libraries (ld-linux, libc) with debug info and make this package a valgrind / gdb dependency. There's no other proper way.
I understand that you don't want to provide debug versions of all the libraries in the base repo, but you really should provide libc-dbg at least because it is a HARD dependency to other packages (such as valgrind).

Reasoning:
1. this is a constant problem for LOTS and LOTS of people (just check the net or even just search this forum, you'll find HUNDREDS of complaints if not more) This is a widely and often reappearing issue.
2. setting up debuginfod is PITA even if the servers are configured correctly (but they are not, see below)
3. even if you set up correctly, it might not work (ISP issues or server issues) when you actually need valgrind
4. servers only provide the most up-to-date packages, so you can't debug a program linked with an older libc
5. the packages are actually MISSING from https://debuginfod.archlinux.org for crying out loud!
6. valgrind error message does not give any clue on debuginfod, it just says "install libc6-dbg" and that's it, causing unmeasurable confusion for newbies

Detailed description (schoolbook example of what's wrong with debuginfod in general):
Usually a "-Syu" and "reboot" is problematic, but solves the issue after all. Not this time. Right now my issue is this (used to be "missing strlen", but this time "missing memcmp"):

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:      memcmp
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.

As you can see, no mention of debuginfod on Arch, and even if you're a veteran like me and you know about https://wiki.archlinux.org/title/Debuginfod, that doesn't help!

None of the known workarounds work this time:

# pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Starting full system upgrade...
 there is nothing to do
# pacman -Qi glibc debuginfod valgrind | grep Version
Version         : 2.41+r48+g5cb575ca9a3d-1
Version         : 0.193-2
Version         : 3.25.1-1
# reboot
----- wait for reboot to make sure the system is using the latest libc and ld-linux -----
# export DEBUGINFOD_URLS="https://debuginfod.archlinux.org"
# debuginfod-find metadata glob '/lib/ld-linux-x86-64.so.2'
{
  "results":[],
  "complete":false
}
#
# debuginfod-find metadata glob '/usr/lib/ld-linux-x86-64.so.2'
{
  "results":[],
  "complete":true
}
# debuginfod-find debuginfo '/usr/lib/ld-linux-x86-64.so.2'
Server query failed: No such file or directory
#

If I check https://debuginfod.archlinux.org/packages then indeed, the server is missing this essential package! Not just the current version, but all versions are missing!
Debuginfod is conceptually broken, and there's nothing I could do to fix it on my side. This causes me a roadblock, I can't work and I suffer serious issues like missing deadlines because of this!

I understand that you don't want to provide debug versions for all the packages, but for crying out loud, please provide just libc-dbg at least, because valgrind is simply DOES NOT WORK without it.

Thanks,
bzt

Last edited by bztarch (2025-08-08 07:37:31)

gromit · 2025-08-08 08:12:16

https://geo.mirror.pkgbuild.com/core-de … kg.tar.zst ?

bztarch · 2025-08-08 09:49:31

gromit wrote:

https://geo.mirror.pkgbuild.com/core-de … kg.tar.zst ?

This is not a solution, just an undocumented workaround in best case. This does not solve the issue that debuginfod can't download the necessary file.

Why are you against adding libc-dbg package to base? It's not a big deal, you already creating libc package, you'd just compile another version of it with debug info, and that's it. That way valgrind could depend on it, there would be no more missing files, no more version issues, no more debuginfod workarounds, no more complaints, etc. Simple and permanent solution to a very annoying problem that's keep popping up for many many users for several years now.

Please consider adding libc-dbg to base. Just that one, the other debug package could be left on debuginfod as those are not hard dependencies to valgrind. Libc-dbg is.

bztarch · 2025-08-08 10:01:51

I've installed that pkg.tar.zst manually, did not help, same issue. No wonder, that's the bad glibc version!

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

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:      memcmp
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've tried to download the URL with exact version match with Arch latest glibc, not working either:

$ sudo pacman -Syu
[sudo] password for bzt: 
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Starting full system upgrade...
 there is nothing to do
$ pacman -Qi glibc | grep Version
Version         : 2.41+r48+g5cb575ca9a3d-1
$ curl "https://geo.mirror.pkgbuild.com/core-debug/os/x86_64/glibc-debug-2.41%2Br48%2Bg5cb575ca9a3d-1-x86_64.pkg.tar.zst"
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

The problem is with debuginfod in the first place, that it needs to download a file which must match Arch base package's version but is not maintained at the same time as the base repo. This is conceptually wrong. This will always break.

Having a libc-dbg (or glibc-debug, no matter the actual name) in base would make this entire problem go away instantly. So, please. Just this one package, because valgrind relies on it, and doesn't even work without.

EDIT: just for the records, adding your server to /etc/pacman.d/mirrorlist throws an error:

error: failed retrieving file 'community.db' from geo.mirror.pkgbuild.com : The requested URL returned error: 404

I'll now try to do a system update regardless, but this is still just an ugly workaround, having valgrind depend on glibc-debug is the one and only permanent solution.

Last edited by bztarch (2025-08-08 10:21:03)

Allan · 2025-08-08 10:16:49

Update your system. You are running unsupported versions of software and complaining they are unsupported. The version of glibc you are running has not been in the repo for over a week - and so its debuginfo was similarly removed.

bztarch · 2025-08-08 10:24:29

Allan wrote:

Update your system. You are running unsupported versions of software and complaining they are unsupported. The version of glibc you are running has not been in the repo for over a week - and so its debuginfo was similarly removed.

NO, I'M NOT. I'm using only supported version, it's not my fault that most servers in mirrorlist throw 404 error and I had to comment them out. I haven't added any mirrors, I'M USING ONLY OFFICIALLY SUPPORTED MIRRORS, that came with pacman -Syu.

Allan wrote:

The version of glibc you are running has not been in the repo for over a week

Why haven't you updated your mirrors then? You can't hardly blame the users for this! Here's my mirrorlist:

Server = https://mirror.lty.me/archlinux/$repo/os/$arch
Server = https://archmirror.it/repos/$repo/os/$arch
Server = https://archlinux.za.mirror.allworldit.com/archlinux/$repo/os/$arch
Server = https://america.mirror.pkgbuild.com/$repo/os/$arch
Server = https://mirror.theash.xyz/arch/$repo/os/$arch

If these weren't updated, that's a maintainer issue, not an end-user issue!

Regardless to mirrors, this problem still presist, because valgrind package does not not depend on glibc-debug, although it can't work without it!

Last edited by bztarch (2025-08-08 10:27:42)

Lone_Wolf · 2025-08-08 10:59:55

https://mirror.lty.me/archlinux/$repo/os/$arch

That's not listed on https://archlinux.org/mirrors/ or https://archlinux.org/mirrors/status/ , so it's not an official archlinux mirror (anymore ?).

What does pacman -Qi pacman-mirrorlist output ?

EDIT : your second mirror archmirror.it is also not on those lists .

Please also post the output of uname -a .

Last edited by Lone_Wolf (2025-08-08 11:02:51)

Scimmia · 2025-08-08 11:23:20

Based on your top mirror, you're OVER A YEAR out of date. You really haven't noticed that you've had no updates for more than 13 months?

bztarch · 2025-08-08 11:32:06

Don't derail the topic, that's a different issue.

This topic is about valgrind crashing due to conceptually flawed debuginfod. This problem annoys LOTS of users, for MANY YEARS now. All the workarounds are insufficient, the same issue pops up constantly.

1. if Arch has a certain glibc version, and debuginfod also downloaded glibc-debug for it, then how come that it stops working one day? I understand that's because the file was removed from the server, but this is still a bug.
2. adding glibc-debug to valgrind dependency would solve the issue
3. adding glibc-debug to the base repo next to the glibc package would guarantee that they are updated at the same time, hence solve this entire problem
4. no need to add any other debug package, just glibc-debug, because that's the only one that valgrind actually relies on.

Scimmia · 2025-08-08 11:35:48

No, this thread is a rant about valgrind crashing due to your system misconfiguration. You keep claiming that it's a widespread issue, it's not.

bztarch · 2025-08-08 11:41:33

Scimmia wrote:

No, this thread is a rant about valgrind crashing due to your system misconfiguration. You keep claiming that it's a widespread issue, it's not.

Definitely not.

This thread is about valgrind really should have correct dependencies, notably glibc-debug.

ps: am I annoyed? Yes, I am, because this issue annoys all developers for many many years now, and I can't work, I'm missing a deadline because of this. Needs a permanent solution.

Allan · 2025-08-08 12:09:58

Valgrind does have the correct dependency...

> pacman -Si valgrind
Repository      : extra
Name            : valgrind
...
Depends On      : glibc  perl  debuginfod

debuginfod is the supported method for accessing debug information.

If that does not suit, use this alias

glibc-debug='pacman -U --noconfirm https://geo.mirror.pkgbuild.com/core-debug/os/x86_64/glibc-debug-$(pacman -S --print-format %v glibc)-x86_64.pkg.tar.zst'

Of course, that command also only works for up-to-date systems.

bztarch · 2025-08-08 12:27:38

Allan wrote:

Valgrind does have the correct dependency...

I'd argue that it does not, even you wrote in your post, that it needs glibc-debug!

Allan wrote:

debuginfod is the supported method for accessing debug information.

Might be true for other libraries, but definitely not for glibc-debug, LOTS of users are complaining for YEARS now because of it (and the bad valgrind message is just making this much worse for the newbies).
You can't call something "supported" when you have so many people constantly complaining about it.

Allan wrote:

Of course, that command also only works for up-to-date systems.

No, this does not solve the issue when someone has a working Arch installation, let's say with glibc-2.41 and glibc-debug-2.41, but suddenly debuginfod breaks the system because 2.41 was deleted from the debuginfod server but america.mirror.pkgbuild.com failed to sync and "pacman -Syu" says "nothing to do", glibc-2.41 is the latest!

Problems from this did occur, and will occur because it is conceptually wrong to install glibc and glibc-debug from two different, unrelated sources. This problem will keep reappearing in the future for sure.

Again, all of this trouble could be simply solved just by adding "depends: glibc-debug" to valgrind. Then the glibc and glibc-debug packages would be updated at the same time, from the same repository, problem solved permanently, no more crashing valgrind.

(And again, I'm not saying this in general about all debug packages, no. I'm only referring to glibc-debug package alone, because it is a hard dependency to valgrind.)

Lone_Wolf · 2025-08-08 20:43:29

Then the glibc and glibc-debug packages would be updated at the same time, from the same repository,

archlinux has debug packages in separate repos:
core-testing-debug, extra-testing-debug, multilib-testing-debug
core-debug, extra-debug, multilib-debug

https://wiki.archlinux.org/title/Debugg … g_packages has more info .

Keep in mind that this forum is not the place to file package issues and very few devs visit it.

I doubt the current repo structure/tooling allows extra packages to depend on packages from core-debug, but if you want the opinion of archlinux valgrind maintainer :
File an issue at https://gitlab.archlinux.org/archlinux/ … d/-/issues

skunktrader · 2025-08-08 22:44:48

bztarch wrote:

EDIT: just for the records, adding your server to /etc/pacman.d/mirrorlist throws an error:
error: failed retrieving file 'community.db' from geo.mirror.pkgbuild.com : The requested URL returned error: 404
I'll now try to do a system update regardless, but this is still just an ugly workaround, having valgrind depend on glibc-debug is the one and only permanent solution.

Your system is way out of date. If you are referencing community in your pacman.conf then you obviously didn't see this

paulf · 2025-10-07 13:50:26

The answer to this is in README_PACKAGERS

-- Do not ship your Linux distro with a completely stripped
/lib/ld.so. At least leave the debugging symbol names on -- line
number info isn't necessary. If you don't want to leave symbols on
ld.so, alternatively you can have your distro install ld.so's
debuginfo package by default, or make ld.so.debuginfo be a
requirement of your Valgrind RPM/DEB/whatever.

If you can't or won't do any of the 3 above then you can always build your own copy of Valgrind with the small patch attached to this bugzilla item

https://bugs.kde.org/show_bug.cgi?id=286864

I still don't see any convincing reply to Julian Seward's comment on 2012-06-30 15:42:31 UTC. "it works on my machine" is not enough.

Arch Linux

#1 2025-08-08 07:20:32

Constant trouble with valgrind

#2 2025-08-08 08:12:16

Re: Constant trouble with valgrind

#3 2025-08-08 09:49:31

Re: Constant trouble with valgrind

#4 2025-08-08 10:01:51

Re: Constant trouble with valgrind

#5 2025-08-08 10:16:49

Re: Constant trouble with valgrind

#6 2025-08-08 10:24:29

Re: Constant trouble with valgrind

#7 2025-08-08 10:59:55

Re: Constant trouble with valgrind

#8 2025-08-08 11:23:20

Re: Constant trouble with valgrind

#9 2025-08-08 11:32:06

Re: Constant trouble with valgrind

#10 2025-08-08 11:35:48

Re: Constant trouble with valgrind

#11 2025-08-08 11:41:33

Re: Constant trouble with valgrind

#12 2025-08-08 12:09:58

Re: Constant trouble with valgrind

#13 2025-08-08 12:27:38

Re: Constant trouble with valgrind

#14 2025-08-08 20:43:29

Re: Constant trouble with valgrind

#15 2025-08-08 22:44:48

Re: Constant trouble with valgrind

#16 2025-10-07 13:50:26

Re: Constant trouble with valgrind

Board footer