memcheck from valgrind-3.0.RC1 loses track of one or more arguments to mmap() when running ld-linux.so.2 directly: "valgrind /lib/ld-linux.so.2 /bin/date". Yes, the tracked code is not quite identical to "valgrind /bin/date", but I believe that nearly all the reported complaints (hundreds if not thousands) are false positive. Chaperon (an independently-developed memory access checker) says that both invocations have no uninit bytes for those complained by memcheck. x86 environment: Fedora Core 4 kernel-2.6.12-1.1398_FC4, glibc-2.3.5-10 -----building from http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 ./configure --with-prefix=/usr/local/valgrind3 make; make install ln -s /usr/local/valgrind3/bin/valgrind /usr/local/bin/valgrind3 # Note: Fedora Core 4 RPM valgrind-2.4.0-3 is also installed; # "which valgrind" ==> /usr/bin/valgrind # This should not matter, but is reported for completeness. ----- execution transcript: valgrind-3.0.RC1 on direct ld-linux.so.2 $ valgrind3 /lib/ld-linux.so.2 /bin/date ==25960== Memcheck, a memory error detector. ==25960== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==25960== Using LibVEX rev 1301, a library for dynamic binary translation. ==25960== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==25960== Using valgrind-3.0.RC1, a dynamic binary instrumentation framework. ==25960== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==25960== For more details, rerun with: -v ==25960== ==25960== Syscall param old_mmap(args) points to uninitialised byte(s) ==25960== at 0x3779474D: mmap (in /lib/ld-2.3.5.so) ==25960== by 0x37784968: _dl_map_object_from_fd (in /lib/ld-2.3.5.so) ==25960== by 0x37787354: _dl_map_object (in /lib/ld-2.3.5.so) ==25960== by 0x37783D26: dl_main (in /lib/ld-2.3.5.so) ==25960== by 0x37791F94: _dl_sysdep_start (in /lib/ld-2.3.5.so) ==25960== by 0x37780DF7: _dl_start (in /lib/ld-2.3.5.so) ==25960== by 0x3777F806: (within /lib/ld-2.3.5.so) ==25960== Address 0x52BFDE44 is on thread 1's stack ==25960== ==25960== Conditional jump or move depends on uninitialised value(s) ==25960== at 0x37784C77: _dl_map_object_from_fd (in /lib/ld-2.3.5.so) ==25960== by 0x37787354: _dl_map_object (in /lib/ld-2.3.5.so) ==25960== by 0x37783D26: dl_main (in /lib/ld-2.3.5.so) ==25960== by 0x37791F94: _dl_sysdep_start (in /lib/ld-2.3.5.so) ==25960== by 0x37780DF7: _dl_start (in /lib/ld-2.3.5.so) ==25960== by 0x3777F806: (within /lib/ld-2.3.5.so) ==25960== ==25960== Use of uninitialised value of size 4 ==25960== at 0x37784C86: _dl_map_object_from_fd (in /lib/ld-2.3.5.so) ==25960== by 0x37787354: _dl_map_object (in /lib/ld-2.3.5.so) ==25960== by 0x37783D26: dl_main (in /lib/ld-2.3.5.so) ==25960== by 0x37791F94: _dl_sysdep_start (in /lib/ld-2.3.5.so) ==25960== by 0x37780DF7: _dl_start (in /lib/ld-2.3.5.so) ==25960== by 0x3777F806: (within /lib/ld-2.3.5.so) ==25960== ==25960== Use of uninitialised value of size 4 ==25960== at 0x37784CB0: _dl_map_object_from_fd (in /lib/ld-2.3.5.so) ==25960== by 0x37787354: _dl_map_object (in /lib/ld-2.3.5.so) ==25960== by 0x37783D26: dl_main (in /lib/ld-2.3.5.so) ==25960== by 0x37791F94: _dl_sysdep_start (in /lib/ld-2.3.5.so) ==25960== by 0x37780DF7: _dl_start (in /lib/ld-2.3.5.so) ==25960== by 0x3777F806: (within /lib/ld-2.3.5.so) ==25960== ... -----
It is the first argument (the address) that it is complaining about, but the value looks sensible.
This small change to glibc/elf/dl-minimal.c works around the problem. Perhaps this will provide a clue about mismatching assumptions. -----glibc-2.3.90-5/elf/dl-minimal.c line 50 void * weak_function __libc_memalign (size_t align, size_t n) { #ifdef MAP_ANON #define _dl_zerofd (-1) #else extern int _dl_zerofd; if (_dl_zerofd == -1) _dl_zerofd = _dl_sysdep_open_zero_fill (); #define MAP_ANON 0 #endif if (alloc_end == 0) { /* Consume any unused space in the last page of our data segment. */ extern int _end attribute_hidden; alloc_ptr = &_end; alloc_end = (void *) 0 + (((alloc_ptr - (void *) 0) + GLRO(dl_pagesize) - 1) & ~(GLRO(dl_pagesize) - 1)); memset(alloc_ptr, 0, alloc_end - alloc_ptr); /* 2005-08-04 valgrind bug */ } -----
Fixed in VEX r1412 valgrind r4868 . See also bug #110183.