Bug 109744 - memcheck loses track of mmap from direct ld-linux.so.2
Summary: memcheck loses track of mmap from direct ld-linux.so.2
Status: RESOLVED WORKSFORME
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.0 SVN
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-28 05:49 UTC by John Reiser
Modified: 2005-10-05 22:30 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Reiser 2005-07-28 05:49:05 UTC
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==
     ...
-----
Comment 1 Tom Hughes 2005-07-28 10:08:04 UTC
It is the first argument (the address) that it is complaining about, but the value looks sensible.
Comment 2 John Reiser 2005-08-22 05:54:08 UTC
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 */
    }
-----
Comment 3 John Reiser 2005-10-05 22:30:02 UTC
Fixed in  VEX r1412  valgrind r4868 .  See also bug #110183.