valgrind 1:3.7.0-6+rpi2 missing suppressions for much of libc

[David Rankin]

Originally filed with https://github.com/raspberrypi/linux/issues/2342, but was advised this is more properly filed here since raspberrypi does not modify `valgrind` in any way.

The package for `valgrind` for Rpi 3 (debian/jessie armf) is missing nearly all suppressions and will through over 4000 errors/warnings related to `Conditional jump or move depends on uninitialised value(s)` for just about every function that allocates or deals with allocated memory, (e.g. `strchr.S:99`, `strlen.S:76`, `__libc_memalign (dl-minimal.c:66)`, `memcpy.S:71`, etc....

I have attempted to update `/usr/lib/valgrind/default.supp` with files generated with `valgrind --gen-suppressions=all`, but I've been met with only limited success. (I reformatted the output to only contain the individual suppression blocks (using `awk` to replace all `'\n'` between opening/closing `{...}` with `'|'`, the sorting piping to `unique -u` to eliminate all duplicates, and then replacing pipe with `'\n'` again to restore the original format and appending to `/usr/lib/valgrind/default.supp` -- but no joy. It did reduce the errors/warnings from `4901/250` to `4223/206`, but the `suppressed` count increased)

A valgrind check of a simple allocation results in over 2700 lines of warnings/errors:

    ==12765== Memcheck, a memory error detector
    ==12765== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
    ==12765== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
    ==12765== Command: ./bin/llwords5
    ==12765==
    ==12765== Conditional jump or move depends on uninitialised value(s)
    ==12765== at 0x4019AB0: index (strchr.S:99)
    ==12765== by 0x4008653: expand_dynamic_string_token (dl-load.c:425)
    ==12765== by 0x4009323: _dl_map_object (dl-load.c:2538)
    ==12765== by 0x4000FD3: map_doit (rtld.c:719)
    ==12765== by 0x401049F: _dl_catch_error (dl-error.c:187)
    ==12765== by 0x4000F5B: do_preload (rtld.c:908)
    ==12765== by 0x4001CA3: handle_ld_preload (rtld.c:1006)
    ==12765== by 0x40039B3: dl_main (rtld.c:1750)
    ==12765== by 0x401713B: _dl_sysdep_start (dl-sysdep.c:249)
    ==12765== by 0x400137B: _dl_start_final (rtld.c:424)
    ==12765== by 0x400160B: _dl_start (rtld.c:652)
    ==12765== by 0x4000CAF: ??? (in /lib/arm-linux-gnueabihf/ld-2.19.so)
    ==12765==
    ==12765== Conditional jump or move depends on uninitialised value(s)
    ==12765== at 0x4019AB4: index (strchr.S:101)
    ==12765== by 0x4008653: expand_dynamic_string_token (dl-load.c:425)
    ==12765== by 0x4009323: _dl_map_object (dl-load.c:2538)
    ==12765== by 0x4000FD3: map_doit (rtld.c:719)
    ==12765== by 0x401049F: _dl_catch_error (dl-error.c:187)
    ==12765== by 0x4000F5B: do_preload (rtld.c:908)
    ==12765== by 0x4001CA3: handle_ld_preload (rtld.c:1006)
    ==12765== by 0x40039B3: dl_main (rtld.c:1750)
    ==12765== by 0x401713B: _dl_sysdep_start (dl-sysdep.c:249)
    ==12765== by 0x400137B: _dl_start_final (rtld.c:424)
    ==12765== by 0x400160B: _dl_start (rtld.c:652)
    ==12765== by 0x4000CAF: ??? (in /lib/arm-linux-gnueabihf/ld-2.19.so)
    <snip>
    ==12765== Conditional jump or move depends on uninitialised value(s)
    ==12765== at 0x49789B0: free_mem (in /lib/arm-linux-gnueabihf/libc-2.19.so)
    ==12765== by 0x49783C3: __libc_freeres (in /lib/arm-linux-gnueabihf/libc-2.19.so)
    ==12765== by 0x4023633: _vgnU_freeres (vg_preloaded.c:61)
    ==12765== by 0x489DAA7: __run_exit_handlers (exit.c:97)
    ==12765== by 0x489DAA7: __run_exit_handlers (exit.c:97)
    ==12765== by 0x489DB3B: exit (exit.c:104)
    ==12765== by 0x4885297: (below main) (libc-start.c:321)
    ==12765==
    ==12765==
    ==12765== HEAP SUMMARY:
    ==12765== in use at exit: 0 bytes in 0 blocks
    ==12765== total heap usage: 33 allocs, 33 frees, 564 bytes allocated
    ==12765==
    ==12765== All heap blocks were freed -- no leaks are possible
    ==12765==
    ==12765== For counts of detected and suppressed errors, rerun with: -v
    ==12765== Use --track-origins=yes to see where uninitialised values come from
    ==12765== ERROR SUMMARY: 4901 errors from 250 contexts (suppressed: 162 from 5)

That makes using `valgrind` almost impossible to use in any meaningful way on Raspberry Pi3. The same code run with proper suppressions, has no warnings or errors (e.g. on openSuSE Leap, Ubuntu, or Archlinux):

    $ valgrind ./bin/llwords5
    ==8415== Memcheck, a memory error detector
    ==8415== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
    ==8415== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
    ==8415== Command: ./bin/llwords5
    ==8415==
    Enter the name of the file: ../dat/captnjack.txt
    This is a tale Of Captain Jack Sparrow A Pirate So Brave On the Seven Seas.
    ==8415==
    ==8415== HEAP SUMMARY:
    ==8415== in use at exit: 0 bytes in 0 blocks
    ==8415== total heap usage: 33 allocs, 33 frees, 884 bytes allocated
    ==8415==
    ==8415== All heap blocks were freed -- no leaks are possible
    ==8415==
    ==8415== For counts of detected and suppressed errors, rerun with: -v
    ==8415== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Whatever suppressions are provided for `valgrind` on these distros completely fix this problem so there are no spurious errors or warnings thrown. I suspect the same thing that is done for the `x86/x86_64` build need to be done here.

[peter green (plugwash)]

To the best of my knowlage valgrind upstream doesn't support armv6. Years ago I was pointed to a patch that made it work on armv6 and applied it in raspbian.

Unfortunately that patch fails to apply on more recent versions of Valgrind resulting in valgrind in raspbian being stuck at a very old version.

If someone wants to work on forward-porting the armv6 fixes to recent Valgrind that would be much appreciated.

[HankB (hbarta)]

I believe I have run into the same issue with valgrind 3.7.0-6+rpi6 (current as of the date of this post.) Usage on Raspberry Pi OS results in thousands of errors reported for code that does not report errors on X86 platforms. I have performed the following tests.

* Download and build valgrind 3.16.0 from https://www.valgrind.org/downloads/current.html#current. It seems to work without this problem. But I am aware that this is not what is in Debian Buster from which Raspberry Pi OS is derived.

* Clone the Debian source for the version which is current on Debian (X86) Buster from https://salsa.debian.org/debian/valgrind/-/tags (valgrind Debian release 1:3.14.0-3), configure and build. I have tested this with my programs and it also works well.

I'm not conversant with what is required to vet a Debian package for Raspberry Pi OS but it seems like the unmodified Debian package is more useful than what is currently in the Raspberry Pi OS repos.

Output from the current Debian Buster version is

```text
hbarta@prelude:~/Programming/game_of_life/C++/build $ ~/valgrind-3.14/bin/valgrind --version
valgrind-3.14.0
hbarta@prelude:~/Programming/game_of_life/C++/build $ ~/valgrind-3.14/bin/valgrind ./test_util
==5893== Memcheck, a memory error detector
==5893== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==5893== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==5893== Command: ./test_util
==5893==
===============================================================================
All tests passed (4 assertions in 2 test cases)

==5893==
==5893== HEAP SUMMARY:
==5893== in use at exit: 0 bytes in 0 blocks
==5893== total heap usage: 2,417 allocs, 2,417 frees, 247,844 bytes allocated
==5893==
==5893== All heap blocks were freed -- no leaks are possible
==5893==
==5893== For counts of detected and suppressed errors, rerun with: -v
==5893== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
hbarta@prelude:~/Programming/game_of_life/C++/build $
```

Output from the older (Raspberry Pi OS) can be viewed at https://pastebin.com/NPEFczB7

Is it possible the armv6 patch is no longer necessary?

[Karl Semich (0xloem)]

this bug makes it very hard to use valgrindn and valgrind is a major tool for finding memory errors that are often also security vulnerabilities.

[Karl Semich (0xloem)]

Here's my current workaround:
1. I built and installed the latest valgrind from source.
2. ~/.valgrindrc:
--sigill-diagnostics=no
--suppressions=/home/pi/.valgrind.supp
3. ~/.valgrind.supp:
{
  libarmmemv7laddr8
  Memcheck:Addr8
  obj:/usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so
}
{
  libarmmemv7laddr4
  Memcheck:Addr4
  obj:/usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so
}
{
  libarmmemv7laddr2
  Memcheck:Addr2
  obj:/usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so
}
{
  libarmmemv7laddr1
  Memcheck:Addr1
  obj:/usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so
}

[Pjfloyd (pjfloyd)]

Hello from upstream.

I'm ignoring the armv6 issue for the moment.

None of these should generate any errors in the first place, so adding suppression is not the answer.

Valgrind should be detecting these functions in libarmmem and redirecting them. There certainly isn't a redirect for that library at the moment. libarmmem is written in assembler, there may be issues handling the ELF sections if it is doing something unusual.

I opened this item

https://bugs.launchpad.net/raspbian/+bug/2051392

With patched libarmmem and patched Valgrind I get no more spurious errors from mem* and str* functions,