Re: possible leak in elf/dl_open.c

[Ulrich Drepper]

Michael Meeks <address@hidden> writes:

>         Assuming memprof is at all capable of finding this sort of leak:

I doubt it is.  It's not working on a level deep enough to handle
this.  Change your program to

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <mcheck.h>
#include <stdlib.h>
#include <dlfcn.h>

int main (int argc, char **argv)
{
        void *handlea;

        mtrace ();
        handlea = dlopen ("/lib/libc.so.6", RTLD_GLOBAL | RTLD_LAZY);
        dlclose (handlea);

        return 0;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

And run

  MALLOC_TRACE=OUT ./program

Then run

  mtrace ./program OUT

and also look at the file OUT.  You'll see no leaks and OUT file will
show you that the 52 bytes are deallocated very late.  The reason is
obvious: the same DSO is used by the program itself and cannot be
deallocated earlier.  The situation isn't different if you are using a
DSO which isn't already used (like /lib/libnss_files.so.2).  And
beside, you cannot expect all memory to be allocated before the
sleep() anyway.  The implementation is allowed to cache information
about DSOs which used to be loaded.  I'm not saying that we do this
but it is perfectly valid.


Like all memory profiling tools which are not operating at the lowest
level memprof will need some way to specify exceptions.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------