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

Bug #1743293 reported by David Rankin
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Raspbian
New
Undecided
Unassigned

Bug Description

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.

Revision history for this message
peter green (plugwash) wrote :

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.

Revision history for this message
HankB (hbarta) wrote :

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?

Revision history for this message
Karl Semich (0xloem) wrote :

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.

Revision history for this message
Karl Semich (0xloem) wrote :

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
}

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.