Valgrind doesn't work in disco [Fatal error at startup: a function redirection which is mandatory for this platform-tool combination cannot be set up.]

[Daniel van Vugt]

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

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.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: valgrind 1:3.14.0-0ubuntu3
ProcVersionSignature: Ubuntu 4.18.0-11.12-generic 4.18.12
Uname: Linux 4.18.0-11-generic x86_64
ApportVersion: 2.20.10-0ubuntu14
Architecture: amd64
Date: Fri Dec 14 17:06:03 2018
InstallationDate: Installed on 2018-12-04 (10 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20181203)
SourcePackage: valgrind
UpgradeStatus: No upgrade log present (probably fresh install)

[Brian Murray (brian-murray)]

Its also worth noting that installing libc6-dbg doesn't help.

[Daniel van Vugt (vanvugt)]

Yes, I already had libc6-dbg installed before reporting the bug.

[Rik Mills (rikmills)]

Blocking autopkgtests (in whole or part) of pyqt5 (hence Qt 5.11.3 transition), apt, Konsole, tilix, gobject-introspection, libwnck3, terminology, gtk+3.0, and probably more....

[Daniel van Vugt (vanvugt)]

The bug also exists in proposed version 3.14.0-2ubuntu1

[Steve Langasek (vorlon)]

This is related to the usrmerge transition. On a freshly debootstrapped disco environment, /lib is a symlink to /usr/lib, which means the canonical path for the debug symbols as looked for by valgrind is /usr/lib/debug/usr/lib/x86_64-linux-gnu/ld-2.28.so which does not exist; only /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.28.so exists and is not found.

Since we do not enforce the usrmerge transition on upgrade to disco, we need to ensure the system can compatibly resolve debug symbols on disco whether or not usrmerge is in effect.

And this problem does not exclusively affect valgrind; other consumers of debug symbols, such as gdb, will also be affected.

So I think the only correct solution here, if we are going to move forward w/ usrmerge by default for disco, is for something (e.g. base-files) to enforce on upgrade that /usr/lib/debug/{lib,bin,sbin} become symlinks to /usr/lib/debug/usr/foo, even if we don't do the usrmerge migration for / itself.

[Matthias Klose (doko)]

dh_strip in debhelper v9 mode doesn't use the filename anymore, so gdb should not affected.

[Steve Langasek (vorlon)]

from IRC discussion, we know that gdb is not affected provided that packages provide .build-id (which glibc does) and we can't think of anything besides gdb, valgrind, and libunwind that uses /usr/lib/debug; so it looks like we should just extend valgrind's lookup path.

[Brian Murray (brian-murray)]

A fix for this bug was uploaded on the 10th but didn't seem to migrate out of -proposed.

[Launchpad Janitor (janitor)]

This bug was fixed in the package valgrind - 1:3.14.0-2ubuntu4

---------------
valgrind (1:3.14.0-2ubuntu4) disco; urgency=medium

  * s390x Fix vector facility bit.

valgrind (1:3.14.0-2ubuntu3) disco; urgency=medium

  * Cherrypick s390x/z13 fixes from valgrind master (3.15) LP: #1799696

valgrind (1:3.14.0-2ubuntu2) disco; urgency=medium

  * debian/patches/usrmerge_support.patch: make valgrind aware of usrmerge;
    if we can't find the debug files under the full objpath (including /usr),
    also try the alternative path by stripping out /usr. (LP: #1808508)

valgrind (1:3.14.0-2ubuntu1) disco; urgency=medium

  * Merge with Debian; remaining changes:
    - Lower over-inflated valgrind-dbg Recommends to Suggests instead.
    - Don't strip vgpreload* on ARM; this results in unusable stack traces
      without valgrind-dbg.
    - Configure with --enable-only64bit on AArch64.
    - Enable parallel builds.

valgrind (1:3.14.0-2) unstable; urgency=medium

  * Fix path in dh_shlibdeps argument on non-x86 arches (Closes: #913822)

valgrind (1:3.14.0-1) unstable; urgency=medium

  * New upstream release (Closes: #913208)
    + Fix assertion `cfsi_fits` failing in simple C program (Closes: #909797)
  * Drop patches backported from upstream
  * Refresh patches
  * Bump Standards-Version to 4.2.1 (no changes needed)
  * Bump debhelper compat level to 11
  * Update install paths
  * Use pkg-config to detect MPI to fix cross-build.
    Thanks to Helmut Grohne for the patch (Closes: #902297)

 -- Dimitri John Ledkov <email address hidden> Mon, 21 Jan 2019 17:13:06 +0000

[Travis Downs (travis-downs)]

> we can't think of anything besides gdb, valgrind, and libunwind that uses /usr/lib/debug

That seems like quite an incredible statement! I can imagine that many debugging and profiling tools will want symbols.

For example, this change is breaking perf right now, as it looks for say libc symbols in /usr/lib/debug/usr/lib/x86_64-linux-gnu/, but the symbols are actually in /usr/lib/debug/lib/x86_64-linux-gnu/.

[Dimitri John Ledkov (xnox)]

@travis-downs this issue was fixed and is no longer monitored, if you have a new bug report against perf, can you please open a new issue?