3

I have RaspberryPi 4B with latest Raspbian fully updated. I am trying to make things work like on RaspberryPi 3B, but even simple hello_world.c executed via valgrind is not without errors. Installed valgrind version is valgrind-3.7.0.

When I run this hello world program:

#include <stdio.h>
int main() {
    puts("Hello, World!");
    return 0;
}

compiled using gcc t.c -o t -g and executed using valgrind ./t I get tons of errors like this:

==5542== Memcheck, a memory error detector
==5542== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==5542== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==5542== Command: ./t
==5542== 
--5542-- WARNING: Serious error when reading debug info
--5542-- When reading debug info from /lib/arm-linux-gnueabihf/ld-2.28.so:
--5542-- Ignoring non-Dwarf2/3/4 block in .debug_info
--5542-- WARNING: Serious error when reading debug info
--5542-- When reading debug info from /lib/arm-linux-gnueabihf/ld-2.28.so:
--5542-- Last block truncated in .debug_info; ignoring
==5542== Conditional jump or move depends on uninitialised value(s)
==5542==    at 0x401A5D0: index (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Conditional jump or move depends on uninitialised value(s)
==5542==    at 0x401A5D4: index (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Conditional jump or move depends on uninitialised value(s)
==5542==    at 0x4008040: _dl_dst_count (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Conditional jump or move depends on uninitialised value(s)
==5542==    at 0x4008288: expand_dynamic_string_token (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Conditional jump or move depends on uninitialised value(s)
==5542==    at 0x401AA80: strlen (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Conditional jump or move depends on uninitialised value(s)
==5542==    at 0x401AA84: strlen (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Conditional jump or move depends on uninitialised value(s)
==5542==    at 0x4017F68: malloc (in /lib/arm-linux-gnueabihf/ld-2.28.so)

.....

==5542== Use of uninitialised value of size 4
==5542==    at 0x40103D4: _dl_init (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Use of uninitialised value of size 4
==5542==    at 0x400FA00: _dl_fixup (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Conditional jump or move depends on uninitialised value(s)
==5542==    at 0x400FA8C: _dl_fixup (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Use of uninitialised value of size 4
==5542==    at 0x400FA8C: _dl_fixup (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Use of uninitialised value of size 4
==5542==    at 0x4015B4C: _dl_runtime_resolve (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
Hello, World!
==5542== Conditional jump or move depends on uninitialised value(s)
==5542==    at 0x40105D0: _dl_fini (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Conditional jump or move depends on uninitialised value(s)
==5542==    at 0x4016178: _dl_sort_maps (in /lib/arm-linux-gnueabihf/ld-2.28.so)
==5542== 
==5542== Use of uninitialised value of size 4
==5542==    at 0x48F8824: free (in /lib/arm-linux-gnueabihf/libc-2.28.so)
==5542== 
==5542== Use of uninitialised value of size 4
==5542==    at 0x499F050: free_mem (in /lib/arm-linux-gnueabihf/libc-2.28.so)
==5542== 
==5542== Conditional jump or move depends on uninitialised value(s)
==5542==    at 0x499F0D0: free_mem (in /lib/arm-linux-gnueabihf/libc-2.28.so)
==5542== 
==5542== Use of uninitialised value of size 4
==5542==    at 0x499EF64: free_slotinfo (in /lib/arm-linux-gnueabihf/libc-2.28.so)
==5542== 
==5542== 
==5542== HEAP SUMMARY:
==5542==     in use at exit: 0 bytes in 0 blocks
==5542==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==5542== 
==5542== All heap blocks were freed -- no leaks are possible
==5542== 
==5542== For counts of detected and suppressed errors, rerun with: -v
==5542== Use --track-origins=yes to see where uninitialised values come from
==5542== ERROR SUMMARY: 4732 errors from 193 contexts (suppressed: 87 from 1)

Does anyone know what to do about this?

Thanks for advance!

jww
  • 97,681
  • 90
  • 411
  • 885
Matej
  • 782
  • 2
  • 6
  • 19
  • 1
    Maybe an outdated version of valgrind? See https://stackoverflow.com/questions/7791012/valgrind-error-conditional-jump-or-move-depends-on-uninitialised-values – jerch Dec 27 '19 at 22:49
  • 2
    This seems to be a problem with `valgrind` or the libraries, not with your program – user3629249 Dec 28 '19 at 00:40
  • 2
    Also see Raspbian Issue 1857741, [Valgrind findings in ld-2.28.so](https://bugs.launchpad.net/raspbian/+bug/1857741). – jww Dec 28 '19 at 02:22
  • @jww Thanks for the help, so compiling newest valgrind from source can solve this issue? – Matej Dec 28 '19 at 14:39
  • 2
    Yes, building Valgrind 3.15 from sources clears the issues. Apparently the problem [old package] is related to Raspbian and ARMv6 support. I can give you instructions for it, but there's not much to it. – jww Dec 28 '19 at 14:41
  • @jww Perfect, valgrind 3.15.0 works well! Thank you – Matej Dec 28 '19 at 19:16
  • @Matej did you just got the tar , extract, configure, compile then install or you modified something in valgrind code/config files/... ? – bruno Apr 19 '20 at 12:01
  • 1
    @bruno yes, I think that I just downloaded tar, extracted, compiled and installed. Here is my setup: `valgrind --version`: `valgrind-3.15.0`, `uname -a`: `Linux server 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux`. CPU is same as yours in the comment above. – Matej Apr 19 '20 at 14:11
  • 1
    @Matej I have exactly the same. I tested again and now I can do "valgrind date" without getting the hundred of messages previously generated. For an other reason I had to reboot my PI4 after the install and first tests, visibly to reboot is necessary, strange. Thank you for your answer – bruno Apr 19 '20 at 14:19
  • @bruno that's strange. So after reboot it works correctly? Also I added valgrind into path in the .bashrc so it requires logout & login to apply changes and make valgrind callable just with `valgrind` command. Maybe if you did it same way that is why reboot was required – Matej Apr 19 '20 at 14:56
  • @Matej I really do not understood. It is not a problem of path to find the new version because the installation *replaced* the rapbian version with the new one, when I saw nothing changed on the behavior I check the date of */usr/local/bin/valgrind* (*/usr/local/bin/valgrind* only gives it) and it was the new one. May be the reboot allowed to load he new version of a module or something equivalent ? – bruno Apr 19 '20 at 15:02
  • @bruno hard to say, maybe reboot reloaded some libraries which caused this problem? Who knows – Matej Apr 19 '20 at 16:28

0 Answers0