Package: valgrind
Version: 1:3.13.0-2+b1
Severity: grave
Justification: doesn't appear to be usable
valgrind in unstable doesn't seem to be able to load the symbol table for
libc6 correctly, resulting in it not instrumenting malloc()
(false negative) and not applying its own default suppressions to
libc6 (false positives). I think this is RC, but please downgrade the
severity if you disagree.
As a baseline, if I run `valgrind ls` in a stretch chroot, I get:
> ==22578== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright
> info
...
> --22578-- Reading syms from /lib/x86_64-linux-gnu/ld-2.24.so
> --22578-- Considering
> /usr/lib/debug/.build-id/26/3f909dbe11a66f7c6233e3ff0521148d9f8370.debug ..
> --22578-- .. build-id is valid
...
> --22578-- REDIR: 0x401af80 (ld-linux-x86-64.so.2:strlen) redirected to
> 0x3809de81 (vgPlain_amd64_linux_REDIR_FOR_strlen)
> --22578-- REDIR: 0x4019830 (ld-linux-x86-64.so.2:index) redirected to
> 0x3809de9b (vgPlain_amd64_linux_REDIR_FOR_index)
...
> --22578-- REDIR: 0x50daf10 (libc.so.6:malloc) redirected to 0x4c2bb40 (malloc)
...
> ==22578== total heap usage: 23 allocs, 9 frees, 56,446 bytes allocated
That makes sense to me: valgrind has injected its instrumented strlen(),
index(), malloc(), etc., and was able to monitor memory allocation
and leaks.
Doing the same thing on unstable, I get:
> ==22631== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
...
> --22631-- Reading syms from /bin/ls
> --22631-- object doesn't have a symbol table
> --22631-- Reading syms from /lib/x86_64-linux-gnu/ld-2.27.so
> --22631-- ELF section outside all mapped regions
> --22631-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
> --22631-- Considering /usr/lib/valgrind/memcheck-amd64-linux ..
> --22631-- .. CRC mismatch (computed 98de4825 wanted 55353537)
> --22631-- Considering /usr/lib/debug/usr/lib/valgrind/memcheck-amd64-linux
> ..
> --22631-- .. CRC is valid
> --22631-- object doesn't have a dynamic symbol table
...
> --22631-- Reading syms from /lib/x86_64-linux-gnu/libselinux.so.1
> --22631-- object doesn't have a symbol table
> --22631-- Reading syms from /lib/x86_64-linux-gnu/libc-2.27.so
> --22631-- ELF section outside all mapped regions
> --22631-- Reading syms from /lib/x86_64-linux-gnu/libpcre.so.3.13.3
> --22631-- Considering /lib/x86_64-linux-gnu/libpcre.so.3.13.3 ..
> --22631-- .. CRC mismatch (computed 0f3a11e2 wanted b2e3bba6)
> --22631-- object doesn't have a symbol table
> --22631-- Reading syms from /lib/x86_64-linux-gnu/libdl-2.27.so
> --22631-- ELF section outside all mapped regions
> --22631-- Reading syms from /lib/x86_64-linux-gnu/libpthread-2.27.so
> --22631-- ELF section outside all mapped regions
> ==22631== Use of uninitialised value of size 8
> ==22631== at 0x4FF24AA: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so)
> ==22631== by 0x4F1FAF5: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so)
> ==22631==
> ==22631== Conditional jump or move depends on uninitialised value(s)
> ==22631== at 0x4FEE987: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so)
> ==22631== by 0x4F1FE53: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so)
> ==22631== by 0x77: ???
> ==22631== by 0x6: ???
> ==22631== by 0x2: ???
> ==22631== by 0x402A49B: ???
> ==22631==
> ==22631== Conditional jump or move depends on uninitialised value(s)
> ==22631== at 0x4F1FE57: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so)
> ==22631== by 0x77: ???
> ==22631== by 0x6: ???
> ==22631== by 0x2: ???
> ==22631== by 0x402A49B: ???
[many more uses of unitialized values elided]
...
> ==22631== HEAP SUMMARY:
> ==22631== in use at exit: 0 bytes in 0 blocks
> ==22631== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
I think those uses of uninitialized values were meant to be suppressed
by /usr/lib/valgrind/default.supp, but were not suppressed because valgrind
couldn't recognise which symbols were involved? And valgrind didn't observe
any memory allocation or deallocation.
I get similar results when using valgrind to run newly-compiled binaries,
including this stupid test program: I don't see the uninitialized symbols
for this one, presumably because it's too trivial, but I also don't see
the 1024-byte leak being diagnosed.
----8<----
#include <stdio.h>
int main (void) { malloc(1024); return puts("hello"); }
----8<----
Regards,
smcv
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1,
'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages valgrind depends on:
ii libc6 2.27-4
ii libc6-dbg 2.27-4
Versions of packages valgrind recommends:
ii gdb 7.12-6+b2
ii valgrind-dbg 1:3.13.0-2+b1
Versions of packages valgrind suggests:
pn alleyoop <none>
pn kcachegrind <none>
pn valgrind-mpi <none>
pn valkyrie <none>
-- no debconf information
