Re: [Valgrind-users] memory access outside allocated areas is not detected

[Gili G. <gi...@br...>]

Hello John.

I already went over the manual, and did not find anything that helped including the --freelist-* flags.
I found answers for all of your questions below, but they are not relevant any more.

Following your advice to construct the smallest stand-alone test case,
I saw that the problem persists if tested at the start of main() when using the same build system.
After a lot of further testing I found the reason:
The executable that valgrind examines is statically linked.
It looks like valgrind must work with a shared glibc to recognize calls to malloc/free.
BTW The identification of uninitialized memory also does not work properly
with the statically linked executable.

I do not see this information in the manual, perhaps it is worth adding to the "Getting Started" section.

In case you still want a full test case, here it is, to be compiled with: gcc -m32 -g -static test.c

#include <stdlib.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
    unsigned int *p;
    printf("======================================================= malloc\n");
    if ((p = malloc(24))) {
        int i;
        for (i=0; i<=5; ++i) {
          p[i]=i;
        }
        p[0]=p[6]+p[7]+p[8];
        p[1]=p[-1]+p[-2]+p[-3];
        printf("======================================================= free\n");
        free(p);
        p[1] = p[0];
    }
    return 0;
}


Thanks for the help,
Gili

> > I am trying to find memory corruption using valgrind/memcheck.
> > I am running a big executable, and noticed that memory access outside allocated areas is not detected. This happens after very many memory allocations are performed.

> How big (numbers, please)?  Run /usr/bin/top and report the VIRT RES SHR amounts
> for the process, both without and with valgrind/memcheck.

> How many allocations and how many calls to free()?
> What is the distribution of block sizes?
> What is the distribution of calls to malloc, realloc, memalign, mmap?

> > I am testing access to illegal memory and finding that access to memory beyond the boundaries of memory just allocated by malloc is not reported.
> > Access to memory after it is freed by free() is not reported.
> > Access to memory which is not mapped in virtual memory is reported.
> > 
> > This is not due to too many errors, and I suspect that the valgrind data structures holding allocations and de-allocations get full, and therefore stop functioning. This is just a guess, I have no information about the mechanism. I do know that the executable uses a big amount of memory allocations.

> There is no limit to the tracking of blocks which have been allocated
> but not yet free()d.  There are some limits on tracking accesses to blocks
> which have been free()d.  The address space is tracked as free, but the
> identity of the most recent block that was associated with that space
> is forgotten.   First, large blocks (--freelist-big-blocks=<number>)
> lose their identity immediately upon free().  Second, there is a queue
> (--freelist-vol=<number>) of free()d small blocks, and old blocks
> are forgotten as new ones are free()d.

> > 
> > Is there a way to check print the  memory allocations and de-allocations that valgrind is tracking at a specific point?

> Read The Fine Manual.  If you don't know where it is,
> then search for "valgrind manual".

> > Is there a limit to the number of allocations that can be handled?

> There is no limit other than total address space available to the process.

> > 
> > I am running on Linux x86_64.
> > I tried using both valgrind-3.8.1 and valgrind-3.5.0 that comes with the open Suse 11.3 I am running on.
> > I tried this with both a 32 bit and a 64 bit executable.
> > Example command line that I use:  valgrind --trace-children=yes --error-limit=no -v ./executable

> Thank you for those details!  You care enough that there is hope for this case.

> > 
> > Does anyone have an idea what to do here?

> Construct the smallest stand-alone test case which illustrates the problem(s),
> and post that code.  If you actually do wade into this then you will find that
> valgrind/memcheck really does work even for "big programs", and that there is
> something unusual about your program or environment that triggers the problems.