Package: valgrind
Version: 1:3.15.0-1
Severity: normal
Tags: upstream

Dear Maintainer,

The only suppression file that Valgrind loads by default is
/usr/lib/$(arch)-linux-gnu/default.supp
(/usr/lib/x86_64-linux-gnu/default.supp on my system). This is
inconvenient, because if you are using Valgrind to debug a program, but
you don't want to debug the libraries that program uses, or maybe one of
the libraries never free()'s some of its memory (for example ncurses or
Readline), then you will need to load the suppression file manually.

Further more (and this is the reason I tagged this bug as `normal'
rather than `wishlist'), some Debian packages install suppression files
to /usr/lib/valgrind/, and they appear to think that those files will be
loaded automatically. For example, the packages python{,2,3} install the
files /usr/lib/valgrind/python{,2,3}.supp. Here is an excerpt from one
of those files:

  # Debian note:
  # The file Misc/valgrind-python.supp is placed in an modified form into the
  # directory /usr/lib/valgrind as python.supp. There's no need to to add it
  # with the --suppressions option.

But in fact you DO need to add it with the --suppressions option.

To prove that Valgrind actually doesn't load these files, create a file
like this one:
#include <stdlib.h>

int main(void) {
  /* Leak some memory. */
  malloc(1);

  return 0;
}
Then create a suppression like this:
{
   Memory leak suppression
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   fun:main
}
Verify that the suppression works:

  $ gcc -o leak leak.c 
  $ valgrind ./leak
  [...]
  ==3428==    definitely lost: 1 bytes in 1 blocks
  [...]
  ==3428==         suppressed: 0 bytes in 0 blocks
  [...]
  $ valgrind --suppressions=leak.supp ./leak
  [...]
  ==3436==    definitely lost: 0 bytes in 0 blocks
  [...]
  ==3436==         suppressed: 1 bytes in 1 blocks
  [...]

And if you copy the suppression to /usr/lib/valgrind/ (or even
/usr/lib/$(arch)-linux-gnu/valgrind/), you will find that it is not
loaded automatically. However, if you copy it to
/usr/lib/$(arch)-linux-gnu/valgrind/default.supp (make a backup of
default.supp first), it *is* loaded automatically.

Correct me if I am mistaken, but I don't believe that Valgrind
suppression files have any way to include other files. If they did, and
it supported shell globs or similar,
/usr/lib/$(arch)-linux-gnu/valgrind/default.supp could simply include
all the *.supp files in /usr/lib/valgrind/, /usr/local/lib/valgrind/,
etc.

But since I don't believe that is possible, the next best solution would
be to modify /usr/bin/valgrind (which is already a wrapper shell script)
to pass a --suppression=FILE for every FILE in /usr/lib/valgrind/*.supp,
/usr/local/lib/valgrind/*.supp, etc. to valgrind.bin. And maybe it could
also parse --default-suppressions=no and not include those files as well
as passing on --default-suppressions=no to valgrind.bin so it doesn't
load the actual default.supp.

Of course, this should probably really be fixed upstream. Maybe the best
solution would be to allow inclusion of other suppression files within
suppression files so that it is easy for the distribution packaging
Valgrind to choose which files/directories are loaded.

Thanks,
Asher

-- 
Steal this tagline.  I did.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (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.29-1
ii  libc6-dbg  2.29-1

Versions of packages valgrind recommends:
ii  gdb           8.3-1
ii  valgrind-dbg  1:3.15.0-1

Versions of packages valgrind suggests:
pn  alleyoop      <none>
pn  kcachegrind   <none>
pn  valgrind-mpi  <none>
pn  valkyrie      <none>

-- no debconf information

Attachment: signature.asc
Description: PGP signature

Reply via email to