[needs-packaging] valgrind on amd64 no longer works with 32-bit binaries

[Ryan C. Gordon]

valgrind works as expected on 64-bit binaries, when using a x86-64 installation...

[icculus@taise ~]$ cat hello.c
#include <stdio.h>
int main(void) { printf("hello.\n"); return 0; }

[icculus@taise ~]$ gcc -m64 -o hello hello.c
[icculus@taise ~]$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
[icculus@taise ~]$ valgrind ./hello
==18291== Memcheck, a memory error detector
==18291== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==18291== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==18291== Command: ./hello
==18291==
hello.
==18291==
==18291== HEAP SUMMARY:
==18291== in use at exit: 0 bytes in 0 blocks
==18291== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==18291==
==18291== All heap blocks were freed -- no leaks are possible
==18291==
==18291== For counts of detected and suppressed errors, rerun with: -v
==18291== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

...however, it does not work with 32-bit binaries...

[icculus@taise ~]$ gcc -m32 -o hello hello.c
[icculus@taise ~]$ file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
[icculus@taise ~]$ valgrind ./hello
==18492== Memcheck, a memory error detector
==18492== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==18492== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==18492== Command: ./hello
==18492==

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: index
valgrind: in an object with soname matching: ld-linux.so.2
valgrind: was not found whilst processing
valgrind: symbols from the object with soname: ld-linux.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: Cannot continue -- exiting now. Sorry.

Please note that "lib6-dbg" is installed on this system...

[icculus@taise ~]$ sudo apt-get install libc6-dbg
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6-dbg is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

This worked with 32-bit binaries in the past (perhaps as recently as 11.04, but I can't say for certain).

This is happening on a fresh 11.04 x86-64 desktop install, default Ubuntu (not Kubuntu, etc). There are some non-default packages installed, like multilib-gcc, as you can tell by the "gcc -m32" command line working, but I don't think these are causing issues.

Let me know if you need more information.

--ryan.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: valgrind 1:3.6.1-0ubuntu3
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
Date: Tue Oct 25 01:13:48 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: valgrind
UpgradeStatus: No upgrade log present (probably fresh install)

[Loïc Minier (lool)]

Works for me with 1:3.6.1-6ubuntu1 from Ubuntu precise:
gcc -m64 -o hello hello.c
valgrind ./hello
==20954== Memcheck, a memory error detector
==20954== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==20954== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==20954== Command: ./hello
==20954==
hello.
==20954==
==20954== HEAP SUMMARY:
==20954== in use at exit: 0 bytes in 0 blocks
==20954== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==20954==
==20954== All heap blocks were freed -- no leaks are possible
==20954==
==20954== For counts of detected and suppressed errors, rerun with: -v
==20954== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

I don't see which packaging change could have fixed this, so this might be a difference in our installed packages; one thing I would have thought would help is installing libc6-dbg:i386, but it turns out it's *not* installed on my system.

However my libc6-dbg:amd64 package does ship /usr/lib/debug/lib32/libc-2.13.so and others.

[Ryan C. Gordon (icculus)]

> Works for me with 1:3.6.1-6ubuntu1 from Ubuntu precise:
> gcc -m64 -o hello hello.c

Yes, that would work, as you tested a 64-bit binary. The problem is that valgrind doesn't work with 32-bit binaries on a 64-bit system. Use -m32 instead of -m64 and see if it changes anything.

(You'll need to apt-get install multilib-gcc for -m32 to work, and maybe ia32-libs, too.)

--ryan.

[Ryan C. Gordon (icculus)]

Quick follow up:

My initial comments said I was on a 11.04 system, which is incorrect; this is happening on 11.10, as the bug metadata correctly states.

I just tested this on Ubuntu 10.10 and Ubuntu 11.04, and both versions have a valgrind that works with 32-bit binaries on a 64-bit system, so this is definitely something that worked recently, and definitely broke in 11.10.

--ryan.

[Loïc Minier (lool)]

Oh wow, sorry for the thinko, I actually typed gcc -m64 machinally instead of -m32; indeed I can reproduce your issue with Ubuntu precise / 12.04 and -m32.

I also confirmed that the initial idea of installing libc6-dbg:i386 was the right one, albeit it has conflicts.

After unpacking /usr/lib/debug/lib/i386-linux-gnu from /libc6-dbg_2.13-20ubuntu5_i386.deb, valgrind passed.

So what this means is that since Ubuntu 11.10, you need to install the multiarch debugging symbols for libc on i386 before valgrind-ing 32-bits binaries on an amd64 system; theoritically this should be achieved with:
apt-get install libc6-dbg:i386

but this breaks with:
Unpacking libc6-dbg:i386 (from .../libc6-dbg_2.13-20ubuntu5_i386.deb) ...
dpkg: error processing /var/cache/apt/archives/libc6-dbg_2.13-20ubuntu5_i386.deb (--unpack):
 './usr/lib/debug/usr/lib/pt_chown' is different from the same file on the system

due to file conflicts

I guess it means we need to break the debugging symbols into two packages, libc-bin-dbg and libc6-dbg.

I don't think there is anything to change in valgrind as I can't think of a way to automatically pull in valgrind's i386-debugging deps, so I'm reassigning the bug to eglibc for the -dbg packaging changes.

Now, the -dbg packages come from Debian and should work in Ubuntu too, but Ubuntu has an additional -dbgsym repository which should have installable packages for i386 and amd64; theoritically, one should be able to add:
deb http://ddebs.ubuntu.com/ <your dist here> main restricted universe multiverse
to sources.list and then install libc6-dbgsym and libc6-dbgsym:i386; unfortunately this fails too because valgrind depends on libc6-dbg and libc6-dbg conflicts with libc6-dbgsym (on any arch); *sigh*.
  However I confirmed that forcing the installation of libc6-dbgsym:i386 solved the problem too.

This is likely going to affect Debian too as it moves to multiarch.

[Claudio G (saxonophon)]

Hello,

I had a very similar problem as descripted above (running valgrind 32-bit on ubuntu 11.10 with 64-bit-arch).
Unpacking to /usr/lib/debug/lib/i386-linux-gnu as descriped above worked for me.

Thank you a lot!!

Greetings,
Claudio

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniele Depetrini (daniele-depetrini)]

I have exactly the same issue. Is that fixed in some dev package to test?

Thanks,

Daniele.

[Enderson Maia (endersonmaia)]

Same problem here.

valgrind-3.6.1-Debian
Ubuntu 11.10

[Heikki Hellgren (heiccih)]

Same problem here. I got the valgrind working with some real stupid hack but not sure what it breaks. Here are the steps:

1. Move from /usr/lib/debug/ the following directories to the following places:
   usr/bin/ -> usr/bintmp/
   usr/lib/ -> usr/libtmp/
   usr/sbin/ -> usr/sbintmp/
   sbin/ -> sbintmp/

2. Unpack the .deb:
   sudo dpkg --unpack /var/cache/apt/archives/libc6-dbg_2.13-20ubuntu5.1_i386.deb

With this the debug system is replaced with 32bit versions of everything and I am not sure if the valgrind can actually be used for 64bit programs after this. This is most probably not the best way to fix this so still waiting for the correction for this bug.

valgrind-3.6.1-Debian
Ubuntu 11.10 64bit 3.0.0-17-generic

[Alex P (initrd-gz)]

Also having this issue. I can't debug my LuaJIT program with this issue, as LuaJIT's custom allocator is mandatory on x64 and Valgrind doesn't track all errors when using it.

[Ryan C. Gordon (icculus)]

As a followup, installing libc6-dbg:i386 on Ubuntu 12.04 works without complaint, and solves this problem.

--ryan.

[Gulshan (gsingh93)]

I can also confirm that sudo apt-get install libc6-dbg:i386 fixed the problem on Ubuntu 12.04

[Adam Conrad (adconrad)]

Right, so this seems to be working fine for >= precise by installing the multiarch libc6-dbg. Marking the eglibc task done, but opening one for valgrind to perhaps improve the error message to suggest this.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ken Sharp (kennybobs)]

This should be fixed upstream.
https://bugs.kde.org/show_bug.cgi?id=286270

Can the maintainer please update the package?

[Brian Murray (brian-murray)]

*** This is an automated message ***

This bug is tagged needs-packaging which identifies it as a request for a new package in Ubuntu. As a part of the managing needs-packaging bug reports specification, https://wiki.ubuntu.com/QATeam/Specs/NeedsPackagingBugs, all needs-packaging bug reports have Wishlist importance. Subsequently, I'm setting this bug's status to Wishlist.